################################################################################ # # Document on the use and difference between CNAMES and VIPs. # # Describes, in the authors view, their uses and pros/cons. # ################################################################################ #Written by Matt Baker, mbaker@computeranddata.com ################################################################################ #VERSION: 2017.09.14.001 ################################################################################ Both allow you a method to abstract the hostname and/or IP of a Unix system. DNS (perspective from DNS) CNAMES are "aliases" in DNS (sometimes called DNS aliases). VIPs (Virtual IP) are a-records in DNS (like a hostname entry). VIPs may, or may not, have reverse lookup (of their IP). It is suggested that you have reverse lookup for VIPs (expecially if you are to use them NFS - NFS requires this for security). Use Both items are solve simalar issues, but in different layers. The common solution (though not the only one) is to virtualize the hostname of a server. So a user connects to a CNAME or a VIP instead of the hostname, which allows for easier migrations/movement of the application to a different server (with a different hostname) and not have an impact on the application connection setup (not tied to a hostname). Each has pros and cons. Each has a better fit for specific situations. Implementation CNAMES are used by global clusters, because they are not tied to subnets like VIPs. Once implemented in DNS, a CNAME points to a DNS a-record (normally a hostname, but could be a VIP as well). No more work is needed for it work (unless in a global cluster and doing a failover, which need the CNAME to point to a different location/datacenter). VIPs can be used by load balancers or OS servers via a hostbased, non-DNS, manual/automated moving (automated would normally be clusteres - servicenames, package IPs, etc). The VIP (IP) can be moved from an OS server/load-balancer (unplumbed) and added (plumbed up) on the correct running OS server/load balancer. CNAME - what it looks like in DNS DNS myappname 86400 IN CNAME hostname1 hostname1 86400 IN A 10.10.100.20 If you are on hostname1, you cannot see that myappname is there except by querying DNS or do a network connection to myappname (as in ssh or telnet). (OS) nslookup myappname hostname1.mydomain.com canonical name = myappname.mydomain.com. Name: hostname1.mydomain.com Address: 10.10.100.20 VIP - what it looks like in DNS and host DNS hostname2 7200 IN A 10.10.200.30 linuxweb 7200 IN A 10.10.200.31 (OS) ifconfig -a eth0 10.10.200.30 #hostname2 eth0:1 10.10.200.31 #vip - linuxweb Pros/cons CNAME One must know what the CNAME is to connect. There isn't a way to discover/find a CNAME, except if someone tells you, or you have access to the DNZ zones where you can then grep for CNAMES and then look for pointers to your a-record (hostname). On a client, you have no idea what server a CNAME belongs to. (centralized: viewed zone admin only). When it moves, one must wait for a DNS update as the cache will be a stale. This can cause some timeouts/delays until the DNS update propogates. -hosts -clients -routers VIP VIPs are easily seen on a server when they are plumbed up by the clutser software, admin, tools. VIPS can be pinged as a separte/unique IP, whereas a CNAME resolves/indrects to the "hostname/server" (a-record) of the cname. This normally means a CNAME will always respond to a ping as long as the base system (server) is running. A VIP will ping if it is plumbed up, which implies the server is up too. That means, a CNAME is always up (for more purposes), but a VIP may or may not respond, which give a better idea if the application setup is up and running. A VIP displays a more active/inactive state of an application, whereas a CNAME (other than global cluster) doesn't as it is always "up/active". VIPs can be put into firewall rules, whereas a CNAME cannot. VIPs are normally required for a cluster service. If it is a global service (across datacenters), then CNAMEs AND VIPs may both be required (VIPs for the local cluster failover, CNAME for the global failover between datacenters/geographic-locaions). VIPs can be put on a local or global load balancer (content switch), whereas a CNAME cannot. VIPs USE UP IPs. Each VIP uses and IP in the subnet, CNAMES are lightwieght and do not use an IP (a-record). VIPs are tied to a subnet - a subnet that the OS has an interface on. Load balancers are more broad, but the load balancer needs to service that particular subnet as well. In DNS, you have no idea what server a VIP belongs to. (decentralized: seen users on the client). When it moves, one must do a gratuitous arp to refresh the MACs in the ARP table. This can cause some timeouts/delays until the ARP entries propogates. (Either down/up the interface - if you can do this without affecting production, run a unique command to do that [i.e. arpinp or other such tools], or wait until cache timesout/update.) -hosts -clients -routers Thoughts Use VIPs as the first choice (over CNAMES). They are most easily seen and managed from the host side. Use CNAMES when you cannot put a VIP on a system, or it is used in a global cluster. Some Linux Examples NOTE: If in the DMZ, you'll need to add the VIP(s) to the firewall rules. REDHAT #unique file for each virtual #where INST is the number you want (as in "1" or "2") INST=1 NIC=eth0 cd /etc/sysconfig/network-scripts cp ifcfg-$NIC ifcfg-$NIC:$INST #or bond0, #or whatever interface you want the vip on #change the DEVICE to $INST #change the IP to the new VIP vi ifcfg-$NIC:$INST DEVICE=eth0:1 <<< edit this to $NIC:$INST IPADDR=x.x.x.x NETMASK=y.y.y.y SUSE #same file, add to same INFC file cd /etc/sysconfig/network vi ifcfg-eth0 #or bond0, or whatever interface you want the vip on # # eth0:1 # LABEL1='1' <<< to right $INST IPADDR1='10.10.1.20' NETMASK1='255.255.255.0' # # eth0:2 # LABEL2='2' IPADDR2='10.10.1.21' NETMASK2='255.255.255.0' # #**OR** # # eth0:1 DEVICE=eth0:1 IPADDR=10.10.1.20 # eth0:2 DEVICE=eth0:2 IPADDR=10.10.1.21 #Then, make it active service network restart #**OR** MYNIC=eth0 MYNICV=eth0:0 MYVIP=10.10.42.49 MYNETMASK=255.255.255.0 MYBROADCAST=10.10.42.255 /sbin/ifconfig $MYNICV $MYVIP netmask $MYNETMASK broadcast $MYBROADCAST FAQ Gratuitous arp so router gets refreshed w/ new IP/MAC /sbin/arping -q -c 4 -U -I $MYNIC -U $MYIP #EOF