Wednesday, February 4, 2015

CRUSHMAP : Example of a Hierarchical Cluster Map [feedly]



----
CRUSHMAP : Example of a Hierarchical Cluster Map
// Ceph

It is not always easy to know how to organize your data in the Crushmap, especially when trying to distribute the data geographically while separating different types of discs, eg SATA, SAS and SSD. Let's see what we can imagine as Crushmap hierarchy.

Take a simple example of a distribution on two datacenters. (Model 1.1)

With the introduction of cache pools we can easily imagine adding ssd drives to our cluster. Take the example of ssd added on new hosts. We then left with two types of disks to manage. In a hierarchy that only describing the physical division of the cluster, we would end up with this type of hierarchy: (Model 1.2)

However, we soon realized that this configuration does not allow to separate the types of discs for use in a specific pool.

To separate these discs and organize Crushmap, the simplest method is still to duplicate the tree from the root. Thus we get two points entered "default" (that could be rename "hdd") and "ssd". An other example with hdd and ssd mixed on same hardware (you need to split each host) : (Model 1.3)

The problem is that we have segmented all the cluster by drive type. It was therefore no more entry point into our tree to select any disk in "dc-1" or in "dc-2". For example, we can no longer define a rule to store data on a specific data center regardless of the type of disc.

What we can do is add other entry points to the root level. For example, to permit access all drives : (Model 1.4)

If we wants to keep a certain logic in the tree, it is also possible to add more levels, some more "logical" for exemple for disks types, and other that represent physical distribution. They can be placed wherever we want and named as we wish. For example, here I added the level "pool" that one could also have called "type" or otherwise. (Model 1.5)

Ok, it works, but it is difficult to read. Moreover, it becomes unreadable when the SSD and HDD are mixed on the same hosts as it involves duplicating each host. Also, there is no more physical data placement logic. We can try to insert a level between HOST and OSD: (Model 1.6)

Ok, it may be advantageous in the case of a small cluster, or in the case where there is no need for other levels. Let's try something else, we can also try using another organization, such as separating the osd in different levels and use that in the specific rules. For examble, have step chooseleaf firstn 5 type host-sata to select sata drive, and step chooseleaf firstn 5 type host-ssd to select ssd drive. (Model 1.7)

But this do NOT WORK. Indeed, the algorithm will try to take an OSD in each branch of the tree. If no OSD is found, it will try again to retrace. But this operation is quite random, and you can easily end up with insufficient replications.

Make the test of this with this crushmap :

  • 1 rule for select one ssd on each DC

  • 1 rule for select one sata on each DC

  • 1 rule for select one sata on 2 diffrents hosts

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65  66  67  68  69  70  71  72  73  74  75  76  77  78  79  80  81  82  83  84  85  86  87  88  89  90  91  92  93  94  95  96  97  98  99  100  101  102  103  104  105  106  107  108  109  110  111  112  113  114  115  116  117  118  119  120  121  122  123  124  125  126  127  128  129  130  131  132  133  134  135  136  137  138  
# begin crush map  tunable choose_local_tries 0  tunable choose_local_fallback_tries 0  tunable choose_total_tries 50  tunable chooseleaf_descend_once 0  tunable chooseleaf_vary_r 0    # devices  device 0 osd.0  device 1 osd.1  device 2 osd.2  device 3 osd.3  device 4 osd.4  device 5 osd.5  device 6 osd.6  device 7 osd.7  device 8 osd.8  device 9 osd.9  device 10 osd.10  device 11 osd.11  device 12 osd.12  device 13 osd.13  device 14 osd.14  device 15 osd.15  device 16 osd.16  device 17 osd.17  device 18 osd.18    # types  type 0 osd  type 1 host-ssd  type 2 host-sata  type 3 datacenter  type 4 root    # buckets  host-sata host-01 {   alg straw   hash 0   item osd.1 weight 1.000   item osd.2 weight 1.000   item osd.3 weight 1.000  }  host-sata host-02 {   alg straw   hash 0   item osd.4 weight 1.000   item osd.5 weight 1.000   item osd.6 weight 1.000  }  host-sata host-03 {   alg straw   hash 0   item osd.7 weight 1.000   item osd.8 weight 1.000   item osd.9 weight 1.000  }  host-sata host-04 {   alg straw   hash 0   item osd.10 weight 1.000   item osd.11 weight 1.000   item osd.12 weight 1.000  }    host-ssd host-05 {   alg straw   hash 0   item osd.13 weight 1.000   item osd.14 weight 1.000   item osd.15 weight 1.000  }  host-ssd host-06 {   alg straw   hash 0   item osd.16 weight 1.000   item osd.17 weight 1.000   item osd.18 weight 1.000  }    datacenter dc1 {   alg straw   hash 0   item host-01 weight 1.000   item host-02 weight 1.000   item host-05 weight 1.000  }  datacenter dc2 {   alg straw   hash 0   item host-03 weight 1.000   item host-04 weight 1.000   item host-06 weight 1.000  }    root default {   alg straw   hash 0   item dc1 weight 1.000   item dc2 weight 1.000  }    # rules    rule sata-rep_2dc {   ruleset 0   type replicated   min_size 2   max_size 2   step take default   step choose firstn 0 type datacenter   step chooseleaf firstn 1 type host-sata   step emit  }    rule ssd-rep_2dc {   ruleset 1   type replicated   min_size 2   max_size 2   step take default   step choose firstn 0 type datacenter   step chooseleaf firstn 1 type host-ssd   step emit  }    rule sata-all {   ruleset 2   type replicated   min_size 2   max_size 2   step take default   step chooseleaf firstn 0 type host-sata   step emit  }      # end crush map

To test the placement, we can use those commands :

crushtool -c crushmap.txt -o crushmap-new.bin  crushtool --test -i crushmap-new.bin --show-utilization --rule 0 --num-rep=2  crushtool --test -i crushmap-new.bin --show-choose-tries --rule 0 --num-rep=2  

Check the utilization :

$ crushtool --test -i crushmap-new.bin --show-utilization  --num-rep=2 | grep ^rule  rule 0 (sata-rep_2dc), x = 0..1023, numrep = 2..2  rule 0 (sata-rep_2dc) num_rep 2 result size == 0:   117/1024  rule 0 (sata-rep_2dc) num_rep 2 result size == 1:   448/1024  rule 0 (sata-rep_2dc) num_rep 2 result size == 2:   459/1024  rule 1 (ssd-rep_2dc), x = 0..1023, numrep = 2..2  rule 1 (ssd-rep_2dc) num_rep 2 result size == 0:    459/1024  rule 1 (ssd-rep_2dc) num_rep 2 result size == 1:    448/1024  rule 1 (ssd-rep_2dc) num_rep 2 result size == 2:    117/1024  rule 2 (sata-all), x = 0..1023, numrep = 2..2  rule 2 (sata-all) num_rep 2 result size == 0:   113/1024  rule 2 (sata-all) num_rep 2 result size == 1:   519/1024  rule 2 (sata-all) num_rep 2 result size == 2:   392/1024  

For all the rules, the number of replication is insufficient for a part of the sample. Particularly for drives in a minor amount (in that case ssd). Looking at the number of retry to chooose an osd, we see that it will be useless to increase the "choose_total_tries" which is sufficient :

$ crushtool --test -i crushmap-new.bin --show-choose-tries --rule 0 --num-rep=2   0:      4298   1:       226   2:       130   3:        59   4:        38   5:        11   6:        10   7:         3   8:         0   9:         2  10:         1  11:         0  12:         2    $ crushtool --test -i crushmap-new.bin --show-choose-tries --rule 1 --num-rep=2   0:      2930   1:       226   2:       130   3:        59   4:        38   5:        11   6:        10   7:         3   8:         0   9:         2  10:         1  11:         0  12:         2    $ crushtool --test -i crushmap-new.bin --show-choose-tries --rule 2 --num-rep=2   0:      2542   1:        52   2:        12  

We can test to increase the number of osd for testing (It's not very pretty…) :

in sata-rep_2dc : step chooseleaf firstn 5 type host-sata

in ssd-rep_2dc : step chooseleaf firstn 5 type host-ssd

in sata-all : step chooseleaf firstn 15 type host-sata

$ crushtool --test -i crushmap-new.bin --show-utilization  --num-rep=2 | grep ^rule  rule 0 (sata-rep_2dc), x = 0..1023, numrep = 2..2  rule 0 (sata-rep_2dc) num_rep 2 result size == 1:   1/1024  rule 0 (sata-rep_2dc) num_rep 2 result size == 2:   1023/1024  rule 1 (ssd-rep_2dc), x = 0..1023, numrep = 2..2  rule 1 (ssd-rep_2dc) num_rep 2 result size == 0:    20/1024  rule 1 (ssd-rep_2dc) num_rep 2 result size == 1:    247/1024  rule 1 (ssd-rep_2dc) num_rep 2 result size == 2:    757/1024  rule 2 (sata-all), x = 0..1023, numrep = 2..2  rule 2 (sata-all) num_rep 2 result size == 2:   1024/1024  

It's better, we see that for the rule "sata-all" it works pretty well, by cons, when there are fewer disk, the number of replications is always not correct. The idea of this distribution was attractive, but quickly realizes that this can not work.

If people have explored this way, or have examples of advanced CRUSHMAP, I encourage you to share them. I'm curious of all that can be done with this. Meanwhile, the best is yet to make it simple to suit your needs. In most cases, the 1.3 model will be perfect.

More details on CRUSH algorithm : http://ceph.com/papers/weil-crush-sc06.pdf


----

Shared via my feedly reader


Sent from my iPhone