]>
Commit | Line | Data |
---|---|---|
11fdf7f2 | 1 | .. _cephfs-multimds: |
7c673cae FG |
2 | |
3 | Configuring multiple active MDS daemons | |
4 | --------------------------------------- | |
5 | ||
6 | *Also known as: multi-mds, active-active MDS* | |
7 | ||
9f95a23c | 8 | Each CephFS file system is configured for a single active MDS daemon |
7c673cae FG |
9 | by default. To scale metadata performance for large scale systems, you |
10 | may enable multiple active MDS daemons, which will share the metadata | |
11 | workload with one another. | |
12 | ||
13 | When should I use multiple active MDS daemons? | |
14 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
15 | ||
16 | You should configure multiple active MDS daemons when your metadata performance | |
17 | is bottlenecked on the single MDS that runs by default. | |
18 | ||
19 | Adding more daemons may not increase performance on all workloads. Typically, | |
20 | a single application running on a single client will not benefit from an | |
21 | increased number of MDS daemons unless the application is doing a lot of | |
22 | metadata operations in parallel. | |
23 | ||
24 | Workloads that typically benefit from a larger number of active MDS daemons | |
25 | are those with many clients, perhaps working on many separate directories. | |
26 | ||
27 | ||
28 | Increasing the MDS active cluster size | |
29 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
30 | ||
9f95a23c TL |
31 | Each CephFS file system has a *max_mds* setting, which controls how many ranks |
32 | will be created. The actual number of ranks in the file system will only be | |
11fdf7f2 TL |
33 | increased if a spare daemon is available to take on the new rank. For example, |
34 | if there is only one MDS daemon running, and max_mds is set to two, no second | |
35 | rank will be created. (Note that such a configuration is not Highly Available | |
36 | (HA) because no standby is available to take over for a failed rank. The | |
37 | cluster will complain via health warnings when configured this way.) | |
7c673cae FG |
38 | |
39 | Set ``max_mds`` to the desired number of ranks. In the following examples | |
40 | the "fsmap" line of "ceph status" is shown to illustrate the expected | |
41 | result of commands. | |
42 | ||
43 | :: | |
44 | ||
45 | # fsmap e5: 1/1/1 up {0=a=up:active}, 2 up:standby | |
46 | ||
11fdf7f2 | 47 | ceph fs set <fs_name> max_mds 2 |
7c673cae FG |
48 | |
49 | # fsmap e8: 2/2/2 up {0=a=up:active,1=c=up:creating}, 1 up:standby | |
50 | # fsmap e9: 2/2/2 up {0=a=up:active,1=c=up:active}, 1 up:standby | |
51 | ||
52 | The newly created rank (1) will pass through the 'creating' state | |
53 | and then enter this 'active state'. | |
54 | ||
55 | Standby daemons | |
56 | ~~~~~~~~~~~~~~~ | |
57 | ||
58 | Even with multiple active MDS daemons, a highly available system **still | |
59 | requires standby daemons** to take over if any of the servers running | |
60 | an active daemon fail. | |
61 | ||
62 | Consequently, the practical maximum of ``max_mds`` for highly available systems | |
11fdf7f2 | 63 | is at most one less than the total number of MDS servers in your system. |
7c673cae FG |
64 | |
65 | To remain available in the event of multiple server failures, increase the | |
66 | number of standby daemons in the system to match the number of server failures | |
67 | you wish to withstand. | |
68 | ||
69 | Decreasing the number of ranks | |
70 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
71 | ||
11fdf7f2 | 72 | Reducing the number of ranks is as simple as reducing ``max_mds``: |
7c673cae FG |
73 | |
74 | :: | |
75 | ||
76 | # fsmap e9: 2/2/2 up {0=a=up:active,1=c=up:active}, 1 up:standby | |
11fdf7f2 TL |
77 | ceph fs set <fs_name> max_mds 1 |
78 | # fsmap e10: 2/2/1 up {0=a=up:active,1=c=up:stopping}, 1 up:standby | |
79 | # fsmap e10: 2/2/1 up {0=a=up:active,1=c=up:stopping}, 1 up:standby | |
80 | ... | |
81 | # fsmap e10: 1/1/1 up {0=a=up:active}, 2 up:standby | |
7c673cae | 82 | |
11fdf7f2 TL |
83 | The cluster will automatically stop extra ranks incrementally until ``max_mds`` |
84 | is reached. | |
7c673cae | 85 | |
c07f9fc5 FG |
86 | See :doc:`/cephfs/administration` for more details which forms ``<role>`` can |
87 | take. | |
88 | ||
11fdf7f2 TL |
89 | Note: stopped ranks will first enter the stopping state for a period of |
90 | time while it hands off its share of the metadata to the remaining active | |
91 | daemons. This phase can take from seconds to minutes. If the MDS appears to | |
92 | be stuck in the stopping state then that should be investigated as a possible | |
93 | bug. | |
7c673cae | 94 | |
11fdf7f2 TL |
95 | If an MDS daemon crashes or is killed while in the ``up:stopping`` state, a |
96 | standby will take over and the cluster monitors will against try to stop | |
97 | the daemon. | |
7c673cae | 98 | |
11fdf7f2 TL |
99 | When a daemon finishes stopping, it will respawn itself and go back to being a |
100 | standby. | |
7c673cae FG |
101 | |
102 | ||
103 | Manually pinning directory trees to a particular rank | |
104 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
105 | ||
106 | In multiple active metadata server configurations, a balancer runs which works | |
107 | to spread metadata load evenly across the cluster. This usually works well | |
108 | enough for most users but sometimes it is desirable to override the dynamic | |
109 | balancer with explicit mappings of metadata to particular ranks. This can allow | |
110 | the administrator or users to evenly spread application load or limit impact of | |
111 | users' metadata requests on the entire cluster. | |
112 | ||
113 | The mechanism provided for this purpose is called an ``export pin``, an | |
114 | extended attribute of directories. The name of this extended attribute is | |
115 | ``ceph.dir.pin``. Users can set this attribute using standard commands: | |
116 | ||
117 | :: | |
31f18b77 | 118 | |
7c673cae FG |
119 | setfattr -n ceph.dir.pin -v 2 path/to/dir |
120 | ||
121 | The value of the extended attribute is the rank to assign the directory subtree | |
122 | to. A default value of ``-1`` indicates the directory is not pinned. | |
123 | ||
124 | A directory's export pin is inherited from its closest parent with a set export | |
125 | pin. In this way, setting the export pin on a directory affects all of its | |
11fdf7f2 | 126 | children. However, the parents pin can be overridden by setting the child |
7c673cae FG |
127 | directory's export pin. For example: |
128 | ||
129 | :: | |
31f18b77 | 130 | |
7c673cae FG |
131 | mkdir -p a/b |
132 | # "a" and "a/b" both start without an export pin set | |
133 | setfattr -n ceph.dir.pin -v 1 a/ | |
134 | # a and b are now pinned to rank 1 | |
135 | setfattr -n ceph.dir.pin -v 0 a/b | |
136 | # a/b is now pinned to rank 0 and a/ and the rest of its children are still pinned to rank 1 | |
31f18b77 | 137 | |
f6b5b4d7 TL |
138 | |
139 | Setting subtree partitioning policies | |
140 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
141 | ||
142 | It is also possible to setup **automatic** static partitioning of subtrees via | |
143 | a set of **policies**. In CephFS, this automatic static partitioning is | |
144 | referred to as **ephemeral pinning**. Any directory (inode) which is | |
145 | ephemerally pinned will be automatically assigned to a particular rank | |
146 | according to a consistent hash of its inode number. The set of all | |
147 | ephemerally pinned directories should be uniformly distributed across all | |
148 | ranks. | |
149 | ||
150 | Ephemerally pinned directories are so named because the pin may not persist | |
151 | once the directory inode is dropped from cache. However, an MDS failover does | |
152 | not affect the ephemeral nature of the pinned directory. The MDS records what | |
153 | subtrees are ephemerally pinned in its journal so MDS failovers do not drop | |
154 | this information. | |
155 | ||
156 | A directory is either ephemerally pinned or not. Which rank it is pinned to is | |
157 | derived from its inode number and a consistent hash. This means that | |
158 | ephemerally pinned directories are somewhat evenly spread across the MDS | |
159 | cluster. The **consistent hash** also minimizes redistribution when the MDS | |
160 | cluster grows or shrinks. So, growing an MDS cluster may automatically increase | |
161 | your metadata throughput with no other administrative intervention. | |
162 | ||
163 | Presently, there are two types of ephemeral pinning: | |
164 | ||
b3b6e05e TL |
165 | **Distributed Ephemeral Pins**: This policy causes a directory to fragment |
166 | (even well below the normal fragmentation thresholds) and distribute its | |
167 | fragments as ephemerally pinned subtrees. This has the effect of distributing | |
168 | immediate children across a range of MDS ranks. The canonical example use-case | |
169 | would be the ``/home`` directory: we want every user's home directory to be | |
170 | spread across the entire MDS cluster. This can be set via: | |
f6b5b4d7 TL |
171 | |
172 | :: | |
173 | ||
174 | setfattr -n ceph.dir.pin.distributed -v 1 /cephfs/home | |
175 | ||
176 | ||
177 | **Random Ephemeral Pins**: This policy indicates any descendent sub-directory | |
178 | may be ephemerally pinned. This is set through the extended attribute | |
179 | ``ceph.dir.pin.random`` with the value set to the percentage of directories | |
180 | that should be pinned. For example: | |
181 | ||
182 | :: | |
183 | ||
184 | setfattr -n ceph.dir.pin.random -v 0.5 /cephfs/tmp | |
185 | ||
186 | Would cause any directory loaded into cache or created under ``/tmp`` to be | |
187 | ephemerally pinned 50 percent of the time. | |
188 | ||
f67539c2 | 189 | It is recommended to only set this to small values, like ``.001`` or ``0.1%``. |
f6b5b4d7 TL |
190 | Having too many subtrees may degrade performance. For this reason, the config |
191 | ``mds_export_ephemeral_random_max`` enforces a cap on the maximum of this | |
192 | percentage (default: ``.01``). The MDS returns ``EINVAL`` when attempting to | |
193 | set a value beyond this config. | |
194 | ||
195 | Both random and distributed ephemeral pin policies are off by default in | |
196 | Octopus. The features may be enabled via the | |
197 | ``mds_export_ephemeral_random`` and ``mds_export_ephemeral_distributed`` | |
198 | configuration options. | |
199 | ||
200 | Ephemeral pins may override parent export pins and vice versa. What determines | |
201 | which policy is followed is the rule of the closest parent: if a closer parent | |
202 | directory has a conflicting policy, use that one instead. For example: | |
203 | ||
204 | :: | |
205 | ||
206 | mkdir -p foo/bar1/baz foo/bar2 | |
207 | setfattr -n ceph.dir.pin -v 0 foo | |
208 | setfattr -n ceph.dir.pin.distributed -v 1 foo/bar1 | |
209 | ||
210 | The ``foo/bar1/baz`` directory will be ephemerally pinned because the | |
211 | ``foo/bar1`` policy overrides the export pin on ``foo``. The ``foo/bar2`` | |
212 | directory will obey the pin on ``foo`` normally. | |
213 | ||
214 | For the reverse situation: | |
215 | ||
216 | :: | |
217 | ||
218 | mkdir -p home/{patrick,john} | |
219 | setfattr -n ceph.dir.pin.distributed -v 1 home | |
220 | setfattr -n ceph.dir.pin -v 2 home/patrick | |
221 | ||
222 | The ``home/patrick`` directory and its children will be pinned to rank 2 | |
223 | because its export pin overrides the policy on ``home``. |