On 11/17/2017 01:26 PM, alpha754293 wrote:
>
> ab;2845089 Wrote:
>> On 11/15/2017 09:26 PM, alpha754293 wrote:
>>>
>>> How to companies/enterprises deal with this then?
>>
>> I am going to apply my own definition to “this”, specifically how to
>> multiple companies handle multiple IP addresses, a common thing, on
>> machines.
>>
>> 1. Their network guys probably understand that names are just aliases
>> primarily meant for humans.
>> 2. They understand that ambiguous names are ambiguous (bad), and use
>> unique ones where needed.
>> 3. They use DNS, not just hostnames, wherever names are necessary.
>>
>>
>
> So, for private networks then, would there be another system on said
> private network then that would be responsible for DNS then?
There could be, sure, but it depends on what you mean by a private
network. Most of my clients use “private” networking internally, meaning
10.x.x.x, 172.16-31.x.x, or 192.168.x.x ranges for actual boxes that are
not accessible (directly) by the Internet. They still have internal DNS
servers, and those internal servers can handle a bunch of networks, some
which they may label as “public” or “dmz”, others they may label as
“backup” (meaning used for backup software), others for data (meaning
iSCSI/FCoE/etc.), and others that are purely “private” (meaning only for
intra-cluster or intra-cloud communications). DNS on any of these
networks could potentially handle IPs for all of them, so you can have a
single DNS server in the “public” company area (but not necessarily out on
the Internet) which will answer requests for any IP anywhere, and with
rules preventing that access from the wrong source IPs. DNS is usually
configured on a per-host basis, so as long as the host can reach the DNS
server via any of its networks, all is well.
>> At this point I am going to insert a definition or two just for clarify
>> so
>> we are on the same page:
>> Hostname: a name assigned to a device on a specific server.
>> DNS name: a name assigned to an IP address in a DNS server, access to
>> DNS
>> clients.
>>
>>
>
> I think that this might be driving a bit of the confusion.
>
> So here is an example, I’ve updated my hostname (via yast) and
> /etc/hosts file so that it now reads something like this:
>
>
> Code:
> --------------------
>
> /etc/hosts
>
> …
> 10.0.1.1 aes0 aes0
> 192.168.1.100 aes00 aes00
> 10.0.1.2 aes1 aes1
> 192.168.1.101 aes01 aes01
>
> --------------------
>
>
> Would that be a hostname or would that be a DNS name?
Just hosts; there is no DNS involved really, though DNS tools WILL query
local hostname/hosts data prior to asking the outside world, as configured
in something like /etc/nsswitch.conf on each machine. The names do not
really matter, in the case above, except to things actually on THIS
machine. If you somehow share the files with other machines, then those
machines get the benefit too. For testing/labs, this is fine, as long as
you do not mind the work and the possible inconsistencies.
>> Also, I would ask specifically what tools you are using, and later, why
>> they need names. On a specific machine perhaps things want names, but I
>> would expect them to want DNS names in most cases, though that is based
>> on
>> my own experience with enterprise software and perhaps other
>> software/scenarios behave differently.
>
> It’s a CAE application. When you set up the cluster, the first field
> that it asks for is the hostname of the node on the cluster.
>
> It is very possible that what the field called “hostname” is really
> asking for is a DNS name, but they don’t make that kind of a distinction
> in the application/setup/configuration of the cluster and neither does
> their documentation.
Fair enough. Chances are good that either will work. If it allows dots,
DNS definitely will. If not, be sure you have your DNS search options
setup properly so that “hostname” is auto-expanded to
“hostname.company.tld” where appropriate.
>>> (i.e. if you’re trying to reach an IP on the private network, use one
>>> specific network interface, but if you’re trying to reach an IP on the
>>> public network, use a different network interface instead. That sort
>> of
>>> thing.)
>>>
>>> That idea with different hostnames helps (I think). I will have to try
>>> it to make sure that the software plays nicely with it.
>>
>> Most places I have seen assign a hostname to a machine, and then assign
>> other host-specific names to the other virtual IPs on the same or
>> differnet NICs within that machine, e.g. mymachine, and then
>> mymachine-backupnet, mymachine-public, mymachine-private. If you get
>> into
>> the OpenStack stuff, particularly from SUSE (SUSE OpenStack Cloud),
>> you’ll
>> see lots of NICs, IPs, and names for them in this way.
>
> To make sure that I am understanding this correctly, does this mean that
> the multiple names point to the same physical NIC (which has a MAC), but
> because of the multiple host-specific names assigned to it (virtual IPs
> for example), it will have multiple IPs per NIC?
>
> Is my understanding about what you wrote correct?
Yes, that’s fine; names only ever resolve to IPs, and then lower (layer 2)
networking layers handle IP-to-MAC resolution, so no need to concern
yourself with that. It’s possible to move IPs among NICs, and the
hostname will always be used by name-resolution technology to find the IP
only, and then the system will decide which NIC should be used, where
appropriate. This could get into other complex things, like NIC bonding,
where multiple NIC actually act as one IP address, in various
configurations, e.g. one can be sender, another receiver, or either can do
both (with switches that support these kinds of things) for greater
throughput, or fault-tolerance. Anyway, names resolve to IPs, and that’s
it. From there, IPs can be wherever, so long as they connect to the right
thing across a wire (it is entirely possible to put a wrong IP on a
network, and it will probably not get anywhere, but it’s possible to do,
so of course get the wires right too, but again you usually do not worry
about that as it is done once and left alone for a long time).
> Wouldn’t that be detrimental to the PHY NIC? (i.e. a gigabit NIC only
> has 1 Gbps of bandwidth. Having multiple IPs point to the same physical
> interface could mean that each IP won’t be able to get it’s maximum
> throughput IF the per-IP (stream?) throughput is already trying to max
> out at the 1 Gbps bandwidth?
Yes, sure. Adding IPs, as you have indicated, will not add throughput,
but that’s not why you add IPs. If you are exhausting a physical NIC with
one IP, adding a second IP will not impact that, other than if now more
traffic comes through that second IP, but that limitation is no different
than if you try to push n+1 packet through the first IP. The benefits of
second IPs are usually higher-level, such as being able to assign one IP
to Apache Tomcat, another to eDirectory, another to a Squid proxy, another
for SSH access. If you want to get 1 gbps through each of those IPs, be
sure you have faster NICs/switches, or use bonding.
> I can see how this can be more useful if the NIC would otherwise be
> under utilized (lots of lower bandwidth services coming together to one
…which is usually the case for a random NIC in a random system…
> PHY NIC so increase that NIC’s utilization), but for HPC applications, I
> can only imagine that I, for example, would likely NOT want to do
> something like this, correct?
>
> (Just checking my understanding of it.)
Sure, depending on the HPC workload. If the workload is the kind where
you send a batch to a computer and then it will come back in ten hours
with a result after trillions of calculations, throughput is probably not
a big deal. If the work is more coordinated in realtime, pushing the
NICs, then your example makes sense. Even then it’s not multiple IPs
causing the problem as much as unrealistic expectations regarding what can
go through all of those IPs at once, but you know that. Chances are good
that if you have multiple physical NICs some of them may be swamped, and
others idle, and that’s normal too. . Backups happen at certain times, but
not all of the time, so they will have idle moments. Administration NICs,
or storage NICs, will have ups and downs. It’s all about the workload.
> Yes, I did use yast to set up the initial configuration (of setting the
> IP addresses for both public and the private networks) as well as its
> associated hostnames for both NICs.
>
> But then I edited /etc/hosts file to add the public and private IP
> addresses going to the other nodes. One of the node is already part of
> the cluster. The others is because in case I want to add the other nodes
> to this cluster. Still undecided for now (as I am now working with the
> job submission part of the process and making sure that’s working
> properly.)
This is exactly what I do; adding “aliases” directly in /etc/hosts is
trivial and usually everything is just fine that way. Adding other
systems to /etc/hosts also works best this way, in my opinion, as I think
Yast does a good job of keeping /etc/hsots authoritative because it is.
Yast modules sometimes do not treat certain files as the authorities
depending on the situation, e.g. for Apache httpd configuration modifying
many of the configuration files you will see notes at the top, “Do not
modify this directly.” because they are overwritten by Yast or other
things regularly, and losing changes is frustrating. That’s a whole other
topic.
> (P.S. Sidebar-- No, I haven’t forgotten about the other testing that you
> had mentioned months ago. I am JUST getting around to that now re: the
> whole X consuming exorbitant amounts of memory/RAM. Also has an impact
> on this clustering testing because I am not sure if I can or would want
> to run the cluster in init 3 or in init 5. TBD… I’ll get back to the
> other thread in a little bit here. Thanks.)
Well my opinion is still the same: do not runs services you do not need.
If it works at runlevel 3 (multi-user.target in systemd terms) then run it
there; the GUI will not help you, it just takes up space in memory, and
apparently it also causes a really weird problem when you start your
services from there.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
…trying to do real work at the same time…