NETWAYS Blog

Ceph: Increasing placement groups in production

by Achim Ledermueller | Oct 25, 2017 | Ceph, Storage und Backup

If you are running a Ceph cluster for several years you will come to the point where the number of placement groups (PGs) no longer fits to the size of your cluster. Maybe you increased the number of OSDs several times, maybe you misjudged the growth of a pool years ago.
Too few PGs per OSD can lead to drawbacks regarding performance, recovery time and uneven data distribution. The latter can be examined with the command ceph osd df. It shows the usage, weight, variance and number of PGs for each OSD as well the min/max variance and the standard deviation of your OSD usage.
Increasing the number of the PGs can lead to a more even data distribution,
but there are several warnings in blogs or mailings lists, especially for production environments. Doubling the PGs (e.g. from 1024 to 2048) may bring down your cluster for some minutes, because creating, activating and peering the new PGs may strongly influence your client’s traffic.
Regarding this warnings, we decided to increase the PGs in slices of 128. Between each slice we waited until all PGs peered successfully, which needed only a few seconds and did not influence the client traffic at all.
Increasing the number of PGs is done with two simple commands:

$ ceph osd set <pool> pg_num <int>
$ ceph osd set <pool> pgp_num <int>

Increasing pg_num creates new PGs, but the data rebalancing and backfilling will only start after increasing pgp_num (the number of placement groups for placement), too. pg_num and pgp_num should always have the same value. Increasing your PGs usually comes with a huge amount of backfilling which should not be a problem for a well configured cluster.

Achim Ledermüller

Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

Read more from Achim and meet the Team

Cloud Management – Teil 1: blkdeviotune/migrate-setmaxdowntime

by Enrico Labedzki | Aug 30, 2017 | Technology, Web Services, Team, Virtualisierung, Serien, Betriebssysteme, OpenNebula, Ceph, NETWAYS, Storage und Backup, Linux, DevOps

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. 😉

Ceph – CRUSH rules über die CLI

by Deniz Armagan | Mar 3, 2017 | Linux, Ceph

Ü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

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

by Lukas Stegmeier | Jan 2, 2017 | OSMC, OSDC, Trainings, WeeklySnap, Ceph, Linux, Foreman, Icinga, Technology, Events, Team, Monitoring & Observability

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 6^th 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

Event Specialist

Lukas ist seit September 2016 bei NETWAYS und hat seine Ausbildung zum Veranstaltungskaufmann bei uns erfolgreich abgeschlossen. Nachdem er alle Bereiche des Eventmanagements kennen gelernt hat, kümmert er sich nun verstärkt um die Schulungsorganisation, unterstützt aber auch bei den Konferenzen. Sportlich verausgabt sich Lukas seit über 10 Jahren intensiv beim Fußball. Seit 2019 trainiert er die C-Jugend des SK Heuchling bei Lauf.

Read more from Lukas and meet the Team

S3 und Swift mit dem Ceph Object Gateway (radosgw)

by Martin Schuster | Dec 21, 2016 | Ceph

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

Senior Systems Engineer

Martin gehört zu den Urgesteinen bei NETWAYS. Wenn keiner mehr weiss, warum irgendwas so ist, wie es ist, dann wird Martin gefragt. Er hat es dann eigentlich immer mal schon vor Jahren gesehen und kann Abhilfe schaffen :). 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 oder zieht einfach um und fängt von vorne an.

Read more from Martin and meet the Team