On 08/15/2013 01:06 AM, Pete Siemsen wrote:
> Your points are well taken. Thanks! I'll reply to just one of the
> issues, and maybe return to the others later.
>
> On Aug 14, 2013, at 7:33 PM, Alan Robertson <[email protected]
> <mailto:[email protected]>> wrote:
>
>>>> This can lead to some circumstances that don't seem to make sense
>>>> at first because the various discovery agents aren't all run at the
>>>> same time. For example, if there is no NIC, then offering a
>>>> service that uses an IP that doesn't seem to use any NIC seems odd
>>>> - but it can happen because we may not have discovered that that
>>>> service is no longer running - or has migrated to another machine.
>>>
>>> It's not odd. There are IPs that don't have NICs. How about 127.0.0.1?
>>>
>>> The NIC and the IP address are not connected. When you pull the
>>> NIC, the IP address doesn't remain in the NIC. The connection
>>> between the NIC and the IP address in the OS. What's missing in the
>>> model is interfaces. When you pull the NIC out, the interface
>>> disappears from the machine. The IP address is connected to the
>>> interface. So: machines have interfaces. Some interfaces have IP
>>> addresses. Some interfaces have NICs, but some don't, like lo0.
>>>
>>> Loopback interfaces can have IP addresses that can be reached from
>>> outside the machine. Our switches and routers do.
>> If you have a route established, that's certainly true. There are
>> some HA techniques (particularly used with LVSs) that rely on this.
>> Not being a network expert, I never fully understood them the way you
>> no doubt do ;-).
>
> I think you should treat switches, routers and hosts (Linux PCs, Macs,
> Windows PCs) as the same basic things in the database. Here's why.
> Take a Linux box with two NICs. Connect it to two IP subnets. No
> problem - it's a multi-homed server. Now reconfigure it slightly to
> make it forward packets from one subnet to the other. Now it's a
> switch or router. Do you want the database to struggle to replace a
> "host" with a "switch" when a software change happens in a device?
There is a distinction that matters a /lot/ to the architecture - it
might or might not be important in the GrandSchemeOfThings, but here it
is...
A *Drone* is a system of any kind with a nanoprobe running on it. That
makes it very different from anything that isn't.
Drones are what do all the work. I can't discover, manage, or monitor
anything without Drones.
In the future (as we discussed in person), it might be the case that I
won't have Drones on all the servers in the environment, but the ones
that I have will be the ones that monitor and discover everything else.
In some theoretical sense, if I have one Drone and disruptive
(network-visible) probes of all kinds, then I don't need more. [Of
course, scaling would suck again, and we would be just like every other
system out there].
But the architecture doesn't fly with zero drones - because they are
what does all the work. All the CMA does is direct drones to do its
bidding.
>From the perspective of this architecture, it is the _only_ kind of
managed system ;-).
One other note - there are things we don't fully understand (and there
always will be). Those appear just as paired IP and MAC addresses -
that is, an IP address on a NIC. We don't know if that's a system by
itself, or if a collection of a dozen of them constitutes a system. But
they are the the same NIC objects and IP address objects that are
attached to switches or Drones.
We know about the NICs, but we don't know about the systems behind the
NICs. This works nicely in the database. If later on, we learn
something about those things, they just become related to the systems
they're attached to.
[One downfall of this representation - if a NIC has multiple unicast MAC
addresses, we see it as multiple NICs. This shows up with virtual
systems being configured in bridging mode. The real NIC may
(effectively) have multiple MAC addresses associated with it. We don't
know they're the same NIC really].
>
> Modern devices like Cisco 6509s are optimized to switch packets, but
> they are just devices with a lot of interfaces. The concepts of
> routers and switches have merged - many "switches" can route, and many
> "routers" can switch. Our switches do both on different sets of
> interfaces, depending on how you configure them. Likewise "hosts" can
> route or switch. These devices are just optimized to do some
> functions better than others.
>
> Some cases to consider:
>
> 1. I once worked at a company where it made sense to put multiple IP
> addresses on router interfaces.
> 2. On a host running IPv6, it's actually hard to have only one IPv6
> address on an interface. IPv6 assumes that you'll have several.
> 3. On routers running BGP, it's often the case that the BGP sessions
> terminate on an IP address configured on the loopback interface. That
> way, the BGP session can survive even if some interfaces go down.
> When I ssh to our routers, I ssh to the IP address that is configured
> on the router's loopback interface. This works even when some of the
> router's interfaces are down. The ssh traffic flows across physical
> NICs, but there is no NIC associated with the loopback interface.
>
> I think the database should allow the representation of the above
> cases. Devices should have interfaces, including lo0. Interfaces
> should have names, and zero or more IP addresses, and zero or one NIC.
> The Common Information Model encapsulates this thinking. Everything
> is a ManagedSystem. A router is a subclass of a ManagedSystem.
It is my understanding that the model I have does encapsulate this
idea. Trust me, you can have multiple IP addresses - ipv4 or ipv6. I
deliberately eliminated the loopback interface - for reasons I can't
remember at the moment. It could easily have been a mistake.
Have you had a chance to read my blog articles on the graph database
"schema"? Those would be good to read.
>
> Anyway, I'm just rambling, but it would a great thing if the database
> is designed to allow these cases, even if the code doesn't initially
> "need" them, so that the application can later grow to do more things.
The nice thing about a schemaless graph diagram - you can represent
_anything_. Schemaless means that the program enforces the schema.
Only when you require changes to the structure and meaning of things
already in the database do you have to restructure the data in the database.
If the new version of your program (the CMA) continues to tolerate the
old data in the database, then you're good.
--
Alan Robertson <[email protected]> - @OSSAlanR
"Openness is the foundation and preservative of friendship... Let me claim
from you at all times your undisguised opinions." - William Wilberforce
_______________________________________________
Assimilation mailing list - Discovery-Driven Monitoring
[email protected]
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/
