Revision 75f49d9b man/gnt-cluster.sgml
b/man/gnt-cluster.sgml | ||
---|---|---|
55 | 55 |
<refsect1> |
56 | 56 |
<title>COMMANDS</title> |
57 | 57 |
|
58 |
<cmdsynopsis> |
|
59 |
<command>command</command> |
|
60 |
<arg>-n <replaceable>node</replaceable></arg> |
|
61 |
<arg choice="req"><replaceable>command</replaceable></arg> |
|
62 |
</cmdsynopsis> |
|
63 |
|
|
64 |
<para> |
|
65 |
Executes a command on all nodes. If the option |
|
66 |
<option>-n</option> is not given, the command will be executed |
|
67 |
on all nodes, otherwise it will be executed only on the node(s) |
|
68 |
specified. Use the option multiple times for running it on |
|
69 |
multiple nodes, like: |
|
70 |
|
|
71 |
<screen> |
|
72 |
# gnt-cluster command -n node1.example.com -n node2.example.com date |
|
73 |
</screen> |
|
74 |
|
|
75 |
</para> |
|
76 |
|
|
77 |
<para>The command is constructed by concatenating all other |
|
78 |
command line arguments. For example, to list the contents of the |
|
79 |
<filename class="directory">/etc</filename> directory on all |
|
80 |
nodes, run: |
|
81 |
|
|
82 |
<screen> |
|
83 |
# gnt-cluster command ls -l /etc |
|
84 |
</screen> |
|
85 |
|
|
86 |
and the command which will be executed will be |
|
87 |
<computeroutput>"ls -l /etc"</computeroutput> |
|
88 |
</para> |
|
89 |
|
|
90 |
|
|
91 |
<cmdsynopsis> |
|
92 |
<command>copyfile</command> |
|
93 |
<arg>-n <replaceable>node</replaceable></arg> |
|
94 |
<arg choice="req"><replaceable>file</replaceable></arg> |
|
95 |
</cmdsynopsis> |
|
96 |
|
|
97 |
<para> |
|
98 |
Copies a file to all or to some nodes. The argument specifies |
|
99 |
the source file (on the current system), the <option>-n</option> |
|
100 |
argument specifies the target node, or nodes if the option is |
|
101 |
given multiple times. If <option>-n</option> is not given at |
|
102 |
all, the file will be copied to all nodes. |
|
103 |
|
|
104 |
Example: |
|
105 |
<screen> |
|
106 |
# gnt-cluster -n node1.example.com -n node2.example.com copyfile /tmp/test |
|
107 |
</screen> |
|
108 |
|
|
109 |
This will copy the file <filename>/tmp/test</filename> from the |
|
110 |
current node to the two named nodes. |
|
111 |
</para> |
|
112 |
|
|
113 |
<cmdsynopsis> |
|
114 |
<command>destroy</command> |
|
115 |
</cmdsynopsis> |
|
116 |
|
|
117 |
<para> |
|
118 |
Remove all configuration files related to the cluster, so that a |
|
119 |
<command>gnt-cluster init</command> can be done again afterwards. |
|
120 |
</para> |
|
121 |
|
|
122 |
<cmdsynopsis> |
|
123 |
<command>getmaster</command> |
|
124 |
</cmdsynopsis> |
|
125 |
|
|
126 |
<para> |
|
127 |
Displays the current master node. |
|
128 |
</para> |
|
129 |
|
|
130 |
<cmdsynopsis> |
|
131 |
<command>info</command> |
|
132 |
</cmdsynopsis> |
|
133 |
|
|
134 |
<para> |
|
135 |
Shows runtime cluster information: cluster name, architecture |
|
136 |
(32 or 64 bit), master node, node list and instance list. |
|
137 |
</para> |
|
138 |
|
|
139 |
<cmdsynopsis> |
|
140 |
<command>init</command> |
|
141 |
<arg>-s <replaceable>secondary_ip</replaceable></arg> |
|
142 |
<arg>-b <replaceable>bridge</replaceable></arg> |
|
143 |
<arg choice="req"><replaceable>clustername</replaceable></arg> |
|
144 |
</cmdsynopsis> |
|
145 |
<para> |
|
146 |
This commands is only run once initially on the first node of |
|
147 |
the cluster. It will initialize the cluster configuration and |
|
148 |
setup ssh-keys and more. |
|
149 |
</para> |
|
150 |
|
|
151 |
<para> |
|
152 |
Note that the <replaceable>clustername</replaceable> is not any |
|
153 |
random name. It has to be resolvable to an IP address using DNS, |
|
154 |
and it is best if you give the fully-qualified domain name. |
|
155 |
</para> |
|
156 |
|
|
157 |
<para> |
|
158 |
The cluster can run in two modes: single-home or dual-homed. In |
|
159 |
the first case, all traffic (both public traffic, inter-node |
|
160 |
traffic and data replication traffic) goes over the same |
|
161 |
interface. In the dual-homed case, the data replication traffic |
|
162 |
goes over the second network. The <option>-s</option> option |
|
163 |
here marks the cluster as dual-homed and its parameter |
|
164 |
represents this node's address on the second network. If you |
|
165 |
initialise the cluster with <option>-s</option>, all nodes added |
|
166 |
must have a secondary IP as well. |
|
167 |
</para> |
|
168 |
|
|
169 |
<para> |
|
170 |
Note that for Ganeti it doesn't matter if the secondary network |
|
171 |
is actually a separate physical network, or is done using |
|
172 |
tunneling, etc. For performance reasons, it's recommended to use |
|
173 |
a separate network, of course. |
|
174 |
</para> |
|
175 |
|
|
176 |
<para> |
|
177 |
The <option>-b</option> option specifies the default bridge for |
|
178 |
instances. |
|
179 |
</para> |
|
180 |
|
|
181 |
<cmdsynopsis> |
|
182 |
<command>masterfailover</command> |
|
183 |
</cmdsynopsis> |
|
184 |
|
|
185 |
<para> |
|
186 |
Failover the master role to the current node. |
|
187 |
</para> |
|
188 |
|
|
189 |
<cmdsynopsis> |
|
190 |
<command>rename</command> |
|
191 |
<arg>-f</arg> |
|
192 |
<arg choice="req"><replaceable>name</replaceable></arg> |
|
193 |
</cmdsynopsis> |
|
194 |
|
|
195 |
<para> |
|
196 |
Renames the cluster and in the process updates the master IP |
|
197 |
address to the one the new name resolves to. At least one of |
|
198 |
either the name or the IP address must be different, otherwise |
|
199 |
the operation will be aborted. |
|
200 |
</para> |
|
201 |
|
|
202 |
<para> |
|
203 |
Note that since this command can be dangerous (especially when |
|
204 |
run over SSH), the command will require confirmation unless run |
|
205 |
with the <option>-f</option> option. |
|
206 |
</para> |
|
207 |
|
|
208 |
<cmdsynopsis> |
|
209 |
<command>verify</command> |
|
210 |
</cmdsynopsis> |
|
211 |
|
|
212 |
<para> |
|
213 |
Verify correctness of cluster configuration. This is safe with |
|
214 |
respect to running instances, and incurs no downtime of the |
|
215 |
instances. |
|
216 |
</para> |
|
217 |
|
|
218 |
<cmdsynopsis> |
|
219 |
<command>version</command> |
|
220 |
</cmdsynopsis> |
|
221 |
|
|
222 |
<para> |
|
223 |
Show the cluster version. |
|
224 |
</para> |
|
58 |
<refsect2> |
|
59 |
<title>COMMAND</title> |
|
60 |
|
|
61 |
<cmdsynopsis> |
|
62 |
<command>command</command> |
|
63 |
<arg>-n <replaceable>node</replaceable></arg> |
|
64 |
<arg choice="req"><replaceable>command</replaceable></arg> |
|
65 |
</cmdsynopsis> |
|
66 |
|
|
67 |
<para> |
|
68 |
Executes a command on all nodes. If the option |
|
69 |
<option>-n</option> is not given, the command will be executed |
|
70 |
on all nodes, otherwise it will be executed only on the |
|
71 |
node(s) specified. Use the option multiple times for running |
|
72 |
it on multiple nodes, like: |
|
73 |
|
|
74 |
<screen> |
|
75 |
# gnt-cluster command -n node1.example.com -n node2.example.com date |
|
76 |
</screen> |
|
77 |
|
|
78 |
</para> |
|
79 |
|
|
80 |
<para> |
|
81 |
The command is constructed by concatenating all other command |
|
82 |
line arguments. For example, to list the contents of the |
|
83 |
<filename class="directory">/etc</filename> directory on all |
|
84 |
nodes, run: |
|
85 |
|
|
86 |
<screen> |
|
87 |
# gnt-cluster command ls -l /etc |
|
88 |
</screen> |
|
89 |
|
|
90 |
and the command which will be executed will be |
|
91 |
<computeroutput>"ls -l /etc"</computeroutput> |
|
92 |
</para> |
|
93 |
</refsect2> |
|
94 |
|
|
95 |
<refsect2> |
|
96 |
<title>COPYFILE</title> |
|
97 |
|
|
98 |
<cmdsynopsis> |
|
99 |
<command>copyfile</command> |
|
100 |
<arg>-n <replaceable>node</replaceable></arg> |
|
101 |
<arg choice="req"><replaceable>file</replaceable></arg> |
|
102 |
</cmdsynopsis> |
|
103 |
|
|
104 |
<para> |
|
105 |
Copies a file to all or to some nodes. The argument specifies |
|
106 |
the source file (on the current system), the |
|
107 |
<option>-n</option> argument specifies the target node, or |
|
108 |
nodes if the option is given multiple times. If |
|
109 |
<option>-n</option> is not given at all, the file will be |
|
110 |
copied to all nodes. |
|
111 |
|
|
112 |
Example: |
|
113 |
<screen> |
|
114 |
# gnt-cluster -n node1.example.com -n node2.example.com copyfile /tmp/test |
|
115 |
</screen> |
|
116 |
|
|
117 |
This will copy the file <filename>/tmp/test</filename> from |
|
118 |
the current node to the two named nodes. |
|
119 |
</para> |
|
120 |
</refsect2> |
|
121 |
|
|
122 |
<refsect2> |
|
123 |
<title>DESTROY</title> |
|
124 |
|
|
125 |
<cmdsynopsis> |
|
126 |
<command>destroy</command> |
|
127 |
</cmdsynopsis> |
|
128 |
|
|
129 |
<para> |
|
130 |
Remove all configuration files related to the cluster, so that |
|
131 |
a <command>gnt-cluster init</command> can be done again |
|
132 |
afterwards. |
|
133 |
</para> |
|
134 |
</refsect2> |
|
135 |
|
|
136 |
<refsect2> |
|
137 |
<title>GETMASTER</title> |
|
138 |
|
|
139 |
<cmdsynopsis> |
|
140 |
<command>getmaster</command> |
|
141 |
</cmdsynopsis> |
|
142 |
|
|
143 |
<para> |
|
144 |
Displays the current master node. |
|
145 |
</para> |
|
146 |
</refsect2> |
|
147 |
|
|
148 |
<refsect2> |
|
149 |
<title>INFO</title> |
|
150 |
|
|
151 |
<cmdsynopsis> |
|
152 |
<command>info</command> |
|
153 |
</cmdsynopsis> |
|
154 |
|
|
155 |
<para> |
|
156 |
Shows runtime cluster information: cluster name, architecture |
|
157 |
(32 or 64 bit), master node, node list and instance list. |
|
158 |
</para> |
|
159 |
</refsect2> |
|
160 |
|
|
161 |
<refsect2> |
|
162 |
<title>INIT</title> |
|
163 |
|
|
164 |
<cmdsynopsis> |
|
165 |
<command>init</command> |
|
166 |
<arg>-s <replaceable>secondary_ip</replaceable></arg> |
|
167 |
<arg>-b <replaceable>bridge</replaceable></arg> |
|
168 |
<arg choice="req"><replaceable>clustername</replaceable></arg> |
|
169 |
</cmdsynopsis> |
|
170 |
|
|
171 |
<para> |
|
172 |
This commands is only run once initially on the first node of |
|
173 |
the cluster. It will initialize the cluster configuration and |
|
174 |
setup ssh-keys and more. |
|
175 |
</para> |
|
176 |
|
|
177 |
<para> |
|
178 |
Note that the <replaceable>clustername</replaceable> is not |
|
179 |
any random name. It has to be resolvable to an IP address |
|
180 |
using DNS, and it is best if you give the fully-qualified |
|
181 |
domain name. |
|
182 |
</para> |
|
183 |
|
|
184 |
<para> |
|
185 |
The cluster can run in two modes: single-home or |
|
186 |
dual-homed. In the first case, all traffic (both public |
|
187 |
traffic, inter-node traffic and data replication traffic) goes |
|
188 |
over the same interface. In the dual-homed case, the data |
|
189 |
replication traffic goes over the second network. The |
|
190 |
<option>-s</option> option here marks the cluster as |
|
191 |
dual-homed and its parameter represents this node's address on |
|
192 |
the second network. If you initialise the cluster with |
|
193 |
<option>-s</option>, all nodes added must have a secondary IP |
|
194 |
as well. |
|
195 |
</para> |
|
196 |
|
|
197 |
<para> |
|
198 |
Note that for Ganeti it doesn't matter if the secondary |
|
199 |
|
|
200 |
network is actually a separate physical network, or is done |
|
201 |
using tunneling, etc. For performance reasons, it's |
|
202 |
recommended to use a separate network, of course. |
|
203 |
</para> |
|
204 |
|
|
205 |
<para> |
|
206 |
The <option>-b</option> option specifies the default bridge |
|
207 |
for instances. |
|
208 |
</para> |
|
209 |
</refsect2> |
|
210 |
|
|
211 |
<refsect2> |
|
212 |
<title>MASTERFAILOVER</title> |
|
213 |
|
|
214 |
<cmdsynopsis> |
|
215 |
<command>masterfailover</command> |
|
216 |
</cmdsynopsis> |
|
217 |
|
|
218 |
<para> |
|
219 |
Failover the master role to the current node. |
|
220 |
</para> |
|
221 |
</refsect2> |
|
222 |
|
|
223 |
<refsect2> |
|
224 |
<title>RENAME</title> |
|
225 |
|
|
226 |
<cmdsynopsis> |
|
227 |
<command>rename</command> |
|
228 |
<arg>-f</arg> |
|
229 |
<arg choice="req"><replaceable>name</replaceable></arg> |
|
230 |
</cmdsynopsis> |
|
231 |
|
|
232 |
<para> |
|
233 |
Renames the cluster and in the process updates the master IP |
|
234 |
address to the one the new name resolves to. At least one of |
|
235 |
either the name or the IP address must be different, otherwise |
|
236 |
the operation will be aborted. |
|
237 |
</para> |
|
238 |
|
|
239 |
<para> |
|
240 |
Note that since this command can be dangerous (especially when |
|
241 |
run over SSH), the command will require confirmation unless |
|
242 |
run with the <option>-f</option> option. |
|
243 |
</para> |
|
244 |
</refsect2> |
|
245 |
|
|
246 |
<refsect2> |
|
247 |
<title>VERIFY</title> |
|
248 |
|
|
249 |
<cmdsynopsis> |
|
250 |
<command>verify</command> |
|
251 |
</cmdsynopsis> |
|
252 |
|
|
253 |
<para> |
|
254 |
Verify correctness of cluster configuration. This is safe with |
|
255 |
respect to running instances, and incurs no downtime of the |
|
256 |
instances. |
|
257 |
</para> |
|
258 |
</refsect2> |
|
259 |
|
|
260 |
<refsect2> |
|
261 |
<title>VERSION</title> |
|
262 |
|
|
263 |
<cmdsynopsis> |
|
264 |
<command>version</command> |
|
265 |
</cmdsynopsis> |
|
266 |
|
|
267 |
<para> |
|
268 |
Show the cluster version. |
|
269 |
</para> |
|
270 |
</refsect2> |
|
225 | 271 |
|
226 | 272 |
</refsect1> |
227 | 273 |
|
Also available in: Unified diff