Network Architecture

Multiple VLAN vs one huge segment

Is it better to have 4 class C vlan or one big /26 network? The answer obviously is "it depends". Some admin like to do things one way and other another. But if there are no specific reasons to choose one versus the other, then I would choose multiple vlans, over merging everything into one. This is because:
  1. Segregate windows from unix. One has lot of broadcast and viruses, the other is closer to nirvana :)
  2. ...

Routable vs Non-Routable IP in DMZ, Internal Network

I choose non-routable for the extra security. Not unless traffic goes thru the NAT device, they can't get to the internet.



Host Naming Convention

Users like to use fun names that they like, such as Abott, Costello, Stinky, Itchy, etc etc. Admins like cryptic name such as sc-smtp01, nacascxch007, etc. But names like pc35c7b6 and s432678 is probably the worse of both world, hated by both users and most sys admins.
Fun Names
Users obviously like to name machines after their favorite mascot, toy, cars, etc. This is definately easy to remember, and if there are only a few machines around, it is fine. But for Sys Admin working at large companies with many machines, not getting any clue of what the machine from the name is usually a draw back. So, it depends whether you want to be a BOFH or a user-pleaser :)
That said, if you are in a university environment, and you see machines named Fermat and Descartes, Hydrogen, Helium, Lithium, Quark, Positron, Photon, you can probably guest that they are machines in the Math, Chem and Physics department. If you are in a dot-com, your web server can probably be named Ferrari, your file server as Durango, and your desktop as Pinto. It is actually very reasonable as long as you publish what the different naming themes are for what purpose.

SysAdmin Names
If you are like me and not creative with naming things, then name the machines with simple acronyms are fine. User desktops probably should be named as lnx-, win-, lap-. Servers would probably be DB01, Web01, App01. Boring, but they are to the point. If you work in large company that spans many location, adding a short prefix to the name is fine, such as CA-Ora01, NY-Web02, etc. But keep them short, don't go overboard and name your exchange server in North America, California, Santa Clara as nacascxch007. sc-xch7 would likely do the job better. Keep the name short and easy to remember, that's what naming is all about!

Cryptic Names
Some admins that really don't know how to name their machines like to put Sercie Code, Serial Number or Asset Code for the machine name. While they claim that this pack lot of info about the machine into the name, it is flawed in the sense that it defeats the purpose of naming the machine: It was supposed to be easy to remember and talk about! Such cryptic names are essentially the worse of both world and hated by users and sys admins alike.
Certainly, if a user call and say my laptop lp3c4d7e battery isn't charing anymore, you can probably call dell and give them the service code that is embeded in the name to get a replacement battery. But if you get a page that pc78df53 has a virus, would you know who to talk or where to go to work on the machine?? Serial number, asset tag, and other such info should be kept in the inventory database and refered when necessary.
The whole exercise of naming machine is that they can be remembered. Those cryptic serial numbers and service code are so hard to remember that IP address may as well be used instead of the machine name!! Furthermore, IP address that one needs to remember is probably only one octet or two. Calling a machine x.x.13.25 is only 4 digits and may add the info that machine is on in building 1, floor 3. It would certainly be easier to remember and more meaningful than tag834761, as asset tag is not used 99.999% of the time of dealing with a machine.

So, in summary, don't upset everyone, try to at least please one set of people, and keep in mind that a name is supposed to be meaningful!

Network Application Tree

Lot of sys admin create a central repository of applications stored on NFS server, so that all users can easily gain access to the same set of applications at the same version. In environment where more than one platoform is supported, there are typically two ways of doing it:
(1) /nfsapp/PLATFORM/program -or-
(2) /nfsapp/program/PLATFORM

PLATFORM could be a cascade of directories that represent things from uname -s, uname -m, uname -r, etc. For example:
  • Linux/i386
  • Linux/x86_64
  • SunOS/5.7
  • SunOS/5.10
  • aix/4.3.3
  • aix/5.1
  • hpux/parisc/10
  • hpux/parisc/10.11
  • hpux/parisc/11.11
  • hpux/itanium/11.23
  • conf
  • src

    Both choices seems largely the same. In reality either choice presents its own set of challenges, as multi-plaform management is obviously more complicated than a single platform. That said, from a sys admin and end user perspective, I would argue that option (1) is better. Developer might have a slight preference for option (2). The reason for the latter is likely because developers start writing code for one platform, then as they port their code to other platform, architecture dependent code get added as sub-directories. But if they plan for multi-architecture from the getgo, (1) wouldn't hinter their work.

    As a sys admin, these are some reasons why I argue (1) is better:

  • User can define variable like NFSBASE=/nfsapp/Linux/x86_64 and then have PATH refer to things as
    $NFSBASE/oracle/bin
    rather than
    /nfsapp/oracle/$OS/$ARCH/bin

  • Application installer usually append its own name at the end of the path. It take less effor to think of installing program to
    /nfsapp/$OS/$ARCH/oracle than
    /nfsapp/oracle/$OS/$ARCH/, which the installer may change to /nfsapp/oracle/$OS/$ARCH/oracle

  • Some applications have sub components. It is more natural to have PATH like
    /nfsapp/$OS/$ARCH/oracle/bin:\
    /nfsapp/$OS/$ARCH/oracle/jdbc/bin:\
    /nfsapp/$OS/$ARCH/oracle/oui/bin:\
    /nfsapp/$OS/$ARCH/oracle/opmn/bin:\
    /nfsapp/$OS/$ARCH/oracle/perl/bin

    than
    /nfsapp/oracle/$OS/$ARCH/bin:\
    /nfsapp/oracle/$OS/$ARCH/jdbc/bin:\
    /nfsapp/oracle/$OS/$ARCH/oui/bin:\
    /nfsapp/oracle/$OS/$ARCH/opmn/bin:\
    /nfsapp/oracle/$OS/$ARCH/perl/bin

    And, really, if using option (2), is one going to create path like /nfsapp/oracle/$OS/$ARCH/jdbc/$OS/$ARCH/bin? Even if one was up to doing it, installer like Oracle OUI won't likely make this easy.
    Oracle is not the only such program. Other examples are gistic/MATLAB_Runtime_Component, GenePatternServer/Tomcat, etc ...

  • Some applications install parallel components (instead of subcomponents). These really want to see their own program name at the end of the install path. Sybyl is one such application. Using Option 1, the insteller is told to use
    /nfsapp/$OS/$ARCH/sybyl8.1
    and it will add parallel componets to:
    /nfsapp/$OS/$ARCH/trigo
    /nfsapp/$OS/$ARCH/sybylAdminTools
    However, if one were to use option 2, the installer would need to see sybyl in the path twice: /nfsapp/sybyl/$OS/$ARCH/sybyl8.1
    Resistance would be futile. If the last sybyl8.1 is removed, (ie used /nfsapp/sybyl/$OS/$ARCH/), the installer would place parallel components at a directory one level higher up, a mess that would eat out the $ARCH part of the PLATFORM definition, like this:
    /nfsapp/sybyl/$OS/$ARCH/
    /nfsapp/sybyl/$OS/trigo/
    /nfsapp/sybyl/$OS/AdminTools/
    This would present quite a hair pulling experience. The components could be mangled up to be redistributed into the original option 2's philosophy of <PROGRAM>/<PLATFORM>, but it would be a lot of work. Most programs natually just expect a local install that did not have to address the PLATFORM info, which is why option 1 is a more natural choice.

  • SunFreeware.com has a lot of programs that can be installed on one machine and copied to network path like $NFSBASE/opt/sfw and they just work. Having to use path like /nfsapp/opt/sfw/$OS/$ARCH/bin, .../sbin is just not as elegant.

  • Option (1) presents a directory tree that can be more easily mounted, to say /usr/local, and still look largely like files installed for the local machine (which can only be one arch).

  • If you started installing apps on NFS server with a single platform, then (1) would be what you started with, and extending it to support additional platform would be fairly easy.
    On the flip side, if you started with multiple platform but they are gradually dying, option (1) presents a structure that would be less tedious to work with when things fall back into a single structure. eg, you will find yourself working almost exclusively on /nfsapp/Linux/x86_64 and forget that /nfsapp/hpux/itanium/11.23 ever existed ;-)

    Challenges present in both (1) and (2):

  • Where to place rchitecturally independent config files?
    Option (1): /nfsapp/NOARCH/program.
    Option (2): /nfsapp/program/NOARCH.
    From the above, option (2) would be more elegant than option (1) as it allows config file closer to the directory of program's binary. However, I suggest that ALL config files be stored in a single directory, a la /etc/profile.d:
    Option 1: /nfsapp/NOARCH/conf
    Option 2: /nfsapp/conf/NOARCH
    or simply, /nfsapp/conf
    This way, one doesn't have to hunt all over the place for the config files (site.cshrc.csh, site.bash.profile, site.alias, tnsnames.ora and schrodinger.hosts will all be found in one place). Oracle now supports the use of environment variable TNSADMIN to point to the dir containing the config files and make this solution easy to implement. But for some older programs, one may have to link files from the program bin directory to the conf to preserve the "natural" location. eg, For old version of oracle, one could have link to a central config file as:
    cd /nfsapp/SunOS/5.8/oracle-client-9i/network/admin/
    ln ../../../../../conf/oracle-client-9i/network/admin/tnsnames.ora ./tnsnames.ora

    Yes, the path is a bit ugly, but it is better than keeping many different versions for each version of the program, for each platform.

  • How to hide the PLATFORM from the user?
    Option (1) allows for /nfsapp/PLATFORM to be mounted as /usr/local (or a subpart like /nfsapp/SunOS/5.9/ to be mounted as /opt/sfw). However, program tha need config files may not work as well. Using hard link instead of symbolic link help help around the problem if everything is based on the same NFS server.
    Alternatively, /usr/local could be a sym link to /net/NFS-server/nfsapp/PLATFORM/, this allow for config file to be sym link to the config dir using ../ path, but csh's cd would show the real dir and make it quite unsigthy to the user :-(. If your orgainzation use sh/ksh/bash, then this isn't as big (or ugly) of a problem.
    Finally, option (2) does not present an easy way to hide other PLATFORM binary on a given machine via mount or sym link of directories.

  • How to hide reduce the number of versions that need to be maintained?
    Many OS provides some sort of binary compatibilities between versions. For example, old binaries produced for Solaris 7 will work in Solaris 9 (the converse may not be true). A lazy (or prudent?) sys admin can sym link such programs into a single directory. However, if the user use csh/tcsh, the cd command would tend to expose all these paths and make things quite ugly (sh/ksh/bash is much better in hiding in this regard). Both option (1) and (2) would result in a spagetti of links, with option (2) having slighly fewer kinks as ARCH is at the end of the path and thus readily visible where things point to.
    PS. AIX 4.3.3 binaries are not compatible with 5.x, HP-UX PA-RISC 11 binaries are not compatible with 11i.

  • Linux has too many flavours and binary are usually not combatible between different versions. Centralized /nfsapp for it works only if all machines are running same OS/Version, or create statically link binaries. uname -r return a quite ugly number that has minor release version, so some scripting may need to be done to make simpler path.



    [Doc URL: http://www.grumpyxmas.com/netArch.html]
    [Doc URL: http://tin6150.github.io/psg/netArch.html]
    (cc) Tin Ho. See main page for copyright info.
    Last updated: 2009-03-03


    hoti1
    bofh1