[gsoc-dev] (no subject)

pranjal mittal mittal.pranjal at gmail.com
Tue May 7 18:45:55 UTC 2013


Ok, got the secondary_node information. As you said, the raw config file
does not seem to organize things well. Maybe that could be improved with
Ganeti.

Just wrote up a small script to extract out  some of the useful part from
this config file:
https://github.com/pramttl/ganeti-cluster-visualisation/blob/master/extract_info.py

*instance_name*, *primary_node*, *secondary_node*
(This is the most basic information required initially for the graphical
models.)




On Tue, May 7, 2013 at 10:23 PM, Lance Albertson <lance at osuosl.org> wrote:

>
> On Tue, May 7, 2013 at 7:45 AM, pranjal mittal <mittal.pranjal at gmail.com>wrote:
>
>> Cool, I understand the difference b/n a node-group and a rack now.
>> I was also going through the cluster sanitized JSON file. (prod.json).
>>
>
> Excellent!
>
> (1)
>> Having a look at the attributes for an Instance, I get this exhaustive
>> list ->
>>
>> [key]  admin_up  beparams  ctime  disk_template  disks  hvparams
>>  hypervisor  mtime  name  network_port  nics  os  osparams  *primary_node
>> *  serial_no  tags  uuid
>>
>> The list does have a primary_node, but does NOT have any *secondary_node
>> *attribute.
>> Without the secondary_node attribute, how do I figure out what is the
>> secondary node for a given instance from such a JSON file?
>>
>
> Looks like the raw config file is structured in a non-intuitive way. You
> normally wouldn't query this directly as the RAPI format is much easier to
> read. However looking at a few examples it looks like the *logical_id*parameter has the two nodes. So if you already know what the primary node
> is the other node listed there is most likely the secondary. I wish I could
> easily give you a sanitized version of the RAPI but there's not a handy
> script for that (yet).
>
>
>> (2)
>> But the attributes of a node do have a *primary_ip* and a *secondary_ip.*
>>
>> What do these mean? Shouldn't a node be having just one IP, (it being on
>> physical machine)
>>
>
> The *gnt-cluster(8)* man page describes this well [1]
>
> *The cluster can run in two modes: single-home or dual-homed. In the
>> first case, all traffic (both public traffic, inter-node traffic and data
>> replication traffic) goes over the same interface. In the dual-homed case,
>> the data replication traffic goes over the second network. The -s
>> (--secondary-ip) option here marks the cluster as dual-homed and its
>> parameter represents this node's address on the second network. If you
>> initialise the cluster with -s, all nodes added must have a secondary IP as
>> well.
>> Note that for Ganeti it doesn't matter if the secondary network is
>> actually a separate physical network, or is done using tunneling, etc. For
>> performance reasons, it's recommended to use a separate network, of course.
>> *
>
>
> [1] http://docs.ganeti.org/ganeti/current/man/gnt-cluster.html
>
> Quick summary: *primary_ip* is the main IP for the machine usually. The *
> secondary_ip* is typically used for DRBD traffic and other backend
> traffic and usually exists on a separate network.
>
> (3) What is the difference between master_candidate and master_capable?
>>
>
> The *ganeti(7)* man page describes this well too [2]. The *
> master_candidate* is a role that a node can be in while *master_capable*is a flag that can be set.
>
> *master_candidate
>> The node receives the full cluster configuration (configuration file and
>> jobs) and can become a master via the gnt-cluster master-failover command.
>> Nodes that are not in this state cannot transition into the master role due
>> to missing state*
>
>
>
>> *master_capable
>> The node can become a master candidate, and furthermore the master node.
>> When this flag is disabled, the node cannot become a candidate; this can be
>> useful for special networking cases, or less reliable hardware.*
>
>
> [2] http://docs.ganeti.org/ganeti/current/man/ganeti.html
>
> --
> Lance Albertson
> Director
> Oregon State University | Open Source Lab
>



-- 
Best Regards,
Pranjal Mittal
B.Tech.  2014
Indian Institute of Technology,BHU
Varanasi, U.P,
India
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/gsoc-dev/attachments/20130508/77c7eecd/attachment-0001.html>


More information about the gsoc-dev mailing list