Seite wählen

NETWAYS Blog

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

OSDC 2017 – Update

From 16.-18. May 2017, the Open Source Data Center Conference will take place in Berlin.
After fixing the hands-on workshops on the first day of the conference, our program is beginning to take shape. Most of our speakers are fixed, so take a look, what awaits you this year.
There will be some great talks on the topics CONTAINERS, INFRASTRUCTURE AS CODE, INTEGRATION and DEPLOYMENT.
The program will be completed within the next few days.
As usual, there will be a relaxed evening event to meet each other in a casual setting.
As always, we are especially grateful to our sponsors, without whose continued support this conference would not be possible.
There’s the Thomas.Krenn AG who supported our conferences for many years now, and we’re happy to know, that they’re sponsoring this year’s OSDC again.
Furthermore we thank the Admin Magazine as well as the Linux Magazin for our media partnership.

First speakers and workshops for the OSDC 2017 announced!

We proudly present our first speakers who will give interesting talks on topics concerning Open Source Data Center solutions.
We’re happy to welcome

…and much more!
In addition, we defined our three workshops that can be booked additionally.

The workshops will be held in a small group, to guarantee an optimal training effect to our attendees. So it is therefore recommended to get your tickets as early as possible.
Be part of the OSDC in Berlin – The conference on application of open source software in data centers and huge IT environments.
We’re looking forward to welcoming you!

Netways Managed Services Status Page – Github is your friend

Unser neues Familienmitglied

Als neuestes Angebot für unsere Hosting-Kunden haben wir nun eine Wartungsseite ins Leben gerufen. Diese ist öffentlich sichtbar unter status.netways.de und soll über Wartungsintervalle unserer Systeme informieren.

Diese Informationen sind in Form eines Blogs aufbereitet und umfassen Meldungen zu Wartungsbeginn, Wartungsende, Verlaufsupdates sowie den betroffenen Systemen und Services.

Blick hinter die Kulissen

Es gibt natürlich sehr viele Varianten, eine Webseite mit Blog umzusetzen. Eines unserer Kriterien war, dass die Wartungsseite extern gehostet sein sollte, um auch bei Wartungen an Webservern oder eventuellen Ausfällen den Informationsfluss zum Kunden garantieren zu können. Des Weiteren sollten Posts schnell und mit Methoden erstellt werden, die das Team bereits im Einsatz hat. Recht schnell fiel die Entscheidung dann auf das Format Github Pages, das all dies nativ bietet.

Wie funktioniert Github Pages?

Github Pages bietet die Möglichkeit, in einem Repository eine Webseite zu erstellen, die unter der URL <username>.github.io online verfügbar ist. Die Struktur der Webseite ist frei wählbar und kann mit den üblichen Layout-Sprachen wie HTML und CSS erstellt werden. Änderungen an der Webseite und das Hinzfügen von Posts können zum einen über die Github-Webseite, aber auch wie gewohnt über die git-Kommandozeile durchgeführt werden.
Nun fragen sich wahrscheinlich viele, wo denn jetzt der Clou an Github Pages ist – Jekyll!
Jekyll ist die Engine, die für uns im Hintergrund den Blog erstellt und die Webseite aktualisiert, sobald ein neuer Post oder eine Änderung an einem bereits bestehenden Post erfolgt. Dies ist nativ in Github Pages eingebaut, so dass hier nichts installiert werden muss – es gilt nur, die von Jekyll erwarteten Konventionen einzuhalten. Dazu gehören z. B. die Directory-Struktur im Repository sowie die File-Namen der Blog-Posts. Damit Jekyll den Blog korrekt generieren kann, werden Layouts hinterlegt, so dass die Posts als schön formatierte Einträge auf der Webseite erscheinen. Mithilfe dieser Layouts kann Jekyll die in Markdown verfassten Inhalte der Posts interpretieren.
Github Pages steht jedem zur Verfügung, der einen Github-Account besitzt. Was man daraus macht, bleibt einem selbst überlassen – jedoch sollte man sich dieses Angebot nicht entgehen lassen.
Als Startpunkt für die Reise durch Github Pages ist das Tutorial von Jonathan McGlone sehr zu empfehlen:
Creating and Hosting a Personal Site on GitHub
Ich wünsche allen Interessierten viel Spaß beim Ausprobieren!

Do not put off till tomorrow…

… what you can do today. For example to submit your proposal for a talk at the Open Source Data Center Conference, taking place on May 16 to 18, 2017 in Berlin. Above all, you can save a lot of money! Until January 31st you can still get your early bird ticket (€100 cheaper!)!
Until the end of January, interested speakers have the opportunity to submit their presentations and case studies proposals via the Call for Papers form at the conference website. So be part of the conference on Open Source Data Center solutions and give the conference a special touch.
The central aspect of the conference is the exchange of experiences between participants, as well as meeting the open source community. Expect lots of new know-how, latest developments and hot discussions about the application of open source software solutions in the field of data centers and huge IT environments. As always, additional workshops on various topics are offered the day prior to the conference.
So now it is your turn to submit your proposal! Be part of the conference and make the OSDC 2017 unique.