Archive for August, 2006

Layer 4-7 Load Balancing using Foundry ServerIron XL

Tuesday, August 8th, 2006

If you’re like me, you use some sort of content switching device in your organization; whether it is a dedicated network appliance such as the Foundry ServerIron, or simply a module in a Cisco switch similar to the CSM. Often times, I find myself “firing and forgetting” about these units until it comes time to deploy a new one. Recently, I was charged with the task of implementing an 8 port Foundry ServerIron XL with Layer3 software, previous to this I had only worked with the older Layer2 models. This article attempts to explain the basic steps to achieve load balancing glory, using one of these devices.

Firstly, I noticed some fairly stark differences between the ServerIron XL, and the older model. One of the large changes is that it will no longer respond on its management port unless you have ip forwarding enabled. (From the router the loadbalancer is connected to, you can ping the load balancer, but from beyond that point, you cannot) This threw me for a slight loop as in the past all of my Foundry work has been Layer2 and worked perfectly.

The answer to this specific problem was the Virtual Interfaces command set, which assigns an IP address to the ‘default’ VLAN (usually VLAN 1) which then routes all IP addresses through that single point. This has the downside of utilizing an extra IP if you are working in public IP space (which I often do).

I will note that one of the nice things about the Foundry load balancer solutions is that you can have a Layer3 switch in between the load balancer and the servers you’re balancing, and my configuration is setup to do this.

Here is the entire configuration file:

ServerIron#sh run
Current configuration:
!
ver 07.3.05cT12
global-protocol-vlan
!
!
server predictor round-robin
!
!
!
!
!
!
!
!
!
!
!
!
!
server real app1 10.1.1.2
port http
port http url “HEAD /”
!
server real app2 10.1.2.2
port http
port http url “HEAD /”
!
server real app3 10.1.3.2
port http
port http url “HEAD /”
!
!
server virtual VIP 192.168.0.5
port http
bind http app1 http app2 http app3 http
!

!

!
vlan 1 name DEFAULT-VLAN by port
router-interface ve 1
!
enable telnet authentication
enable telnet password …..
enable super-user-password …..
ip forward
ip address 192.168.0.3 255.255.255.0
ip default-gateway 192.168.0.1
username admin privilege 5 password …..
password-change any
interface e 1
no cache-group
no spanning-tree
!
interface e 2
no cache-group
no spanning-tree
!
interface ve 1
ip address 192.168.0.4 255.255.255.0
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
end

As you can see, the ServerIron XL and all of the real servers actually exist on seperate networks; they are seperated by a Watch Guard X500 security appliance. On my router I have a vlan setup for 192.168.0.1 255.255.255.0 which is the gateway for the ServerIron XL, then I have static routes from the router, to the Firebox X500 and the ServerIron XL for 10.1.1.0/29, 10.1.2.0/29, and 10.1.3.0/29.

I will highlight certain parts of the configuration:

#server predictor round-robin

This command tells the load balancer to use round robin as the method of balancing connections.

#server real 10.1.x.x
#port http
#port http url “HEAD /”

These commands tell the load balancer which servers actually have the HTTP content on it.

#server virtual VIP 192.168.0.5
#port http
#bind http app1 http app2 http app3 http

This command creates a VIRTUAL server, which is where you would point your client browsers in order to access the round robin configured load balancing.

#vlan 1 name DEFAULT-VLAN by port
# router-interface ve 1

By default all ports on the ServerIron XL are assigned to port 1, this command allows the switch to use ve1 to access the ‘default-gateway’.

#ip forward

Enables IP forwarding, so that the load balancer can access the outside world.

#ip address 192.168.0.3 255.255.255.0

This is the management IP of the ServerIron XL

#ip default-gateway 192.168.0.1

This is the default gateway of the ServerIron XL

#interface ve 1
# ip address 192.168.0.4 255.255.255.0

This command assigns an IP address to the virtual interface Ve1 which allows the ServerIron XL to create static routes to reach the default-gateway.

The above configuration is very short, and is just an example of how quick and easy it is to leverage these devices in order to provide Content Load balancing for your critical Web, or other sorts of applications.

I hope you find this guide useful.

-Drew

Reboot a Windows 2003 Server remotely without remote desktop

Tuesday, August 8th, 2006

Most, if not all system administrators with a Windows 2003 server machine under their control has had the unpleasant experience of needing to reboot a server in the middle of the night or while they are hundreds of miles away from the data center. Every once in awhile, remote desktop may not be desirable or available and the server still needs to be rebooted. I present a method to reboot a Windows 2003 Server remotely without Remote Desktop.

Open a command prompt:

click start, navigate to  run > type cmd.exe and press enter

For this example I will assume the IP address of your server is 192.168.0.1

Create a RPC connection to 192.168.0.1:

net use \\192.168.0.1

You will need to authenticate using an administrator account:

The password or user name is invalid for \\192.168.0.1Enter the user name for ‘192.168.0.1’ : administrator

Enter the password for 192.168.0.1: password

The command completed successfully.

Then if you issue the following command, windows will shutdown and the server will restart (note: -f will force a reboot, you may not need it):

shutdown -r -f -m \\192.168.0.1

This method of rebooting has saved me many late night trips to the datacenter when Remote Desktop acts up.

Have fun!

-Drew

Boot Ghost via PXE/LAN

Tuesday, August 8th, 2006

Anyone with a large number of Windows hosts (or a small number of hosts and a small number of incompetent users) in their network should be familiar with Norton Ghost. If you are like me, and use Ghost anywhere from 3-6 times in a single day, breaking out floppy disks or CD-ROMs every time a box needs to be imaged can be tedious. This article describes how to create a network bootable Ghost environment. 

Norton Ghost is a product that I have had a love/hate relationship with ever since I began using the corporate edition of Ghost 8.0. It handles the imaging and restoration of Windows based PCs and servers perfectly, whilst the Linux support leaves entirely too much to be desired. Other commercial products such as Acronis TrueImage handle Linux much better from what I’ve seen, but is also prone to destroying the occasional boot loader or two (or all?).

If you’ve never used Norton Ghost, here is a little background on the process involved. First you configure a PC or Server to be your “master client”, then you use Ghost (I always used GhostCast) to create an “Image” of the hard drive (or drives) that system is based on. What this does for you is allows you to quickly restore to a consistent baseline without having to re-install Windows, download patches, re-secure everything, and et cetera. In essence, it saves a huge amount of time.

At my current place of employment we spin-up maybe 10 boxes in a single day, which means that we had to swap sets of ghost floppies (or CD-ROMs) each time we did this, and although it was not that big of a deal, occasionally having bad media at a critical point in a system rebuild is entirely unacceptable. This is where PXE comes in.

PXE, or Pre-eXcution Environment, (assuming you have a NIC created before 2001) allows your server or workstation to boot without any disk media what so ever, and you can boot just about anything you can imagine via PXE. Here is a brief synopsis of how PXE interacts with your system and network as a whole.

The workstation boots, if PXE is selected as a boot option the workstation attempts to obtain an IP address from a DHCP or BOOTP server on your network. If the server does obtain a DHCP or BOOTP IP address, it will then look for a certain flag that your DHCP server sends out saying “I want you to boot from this image”. The workstation then looks for another DHCP flag which tells it where to find the image in question, the workstation downloads the image, and attempts (you hope) to execute it.

I am a big proponent of open source technology, I wanted to use as many open source tools as I could to complete this project. The software that I used for this particular project is: ISC DHCP 3, pxelinux, Peter Anvin’s TFTPd-hpa, there are multiple open source TFTP daemons available, but this is the best one I could find. I must admit I did steer away from open source for one component of this project, as I used WinImage to create the single image from both of the Ghost boot floppies.

I installed all of these daemons on Centos 4.2, I ran Winimage on a Windows 2003 Server, and I also used the same Windows Server to create my Ghost media. I like CentOS because of the long support cycles for patches, the fact that it works 100X better than Fedora, and the fact that it had all of the daemons I needed compiled as RPMs.

You will need:
A Linux Server (Redhat, Fedora, Debian, CentOs, Enter favorite distribution here)
ISC DHCP 3.0
Syslinux (if you have linux, you likely have this already)
tftp-hpa
WinImage or another tool to create bootable images.
A Windows PC or Server from which to generate your boot image.
An old crappy workstation to test everything on.

Since I used CentOs 4.2 to construct my setup, I will assume everyone is using CentOS 4.2, and give commands related to that particular distribution; however the configuration files for all of the server related items mentioned should be distribution independant.

First lets install the daemons we need.

yum install dhcp
yum install tftp-server
yum install syslinux

You may or may not notice that by installing tftp-server a directory named tftpboot was placed in your root. This directory is where we will be storing most of our pertinent PXE files. Now we will finish setting up your PXE server.

cp /usr/lib/syslinux/pxelinux.0 /tftpboot
mkdir pxelinux.cfg

This moves the PXE loader to the appropriate location, and creates the configuration directory. We will come back to the PXE configuration later. Now we must configure ISC DHCP. DHCPD’s configuration file is /etc/dhcpd.conf on CentOS 4.2 and other Redhat Derivitives.

Here is an example /etc/dhcpd.conf

authoritative;
allow booting;
ddns-update-style none;
next-server 10.1.5.1;
default-lease-time -1;
filename “pxelinux.0″;
subnet 10.1.5.0 netmask 255.255.255.0 {
range 10.1.5.128 10.1.5.254;
}

Caution: You do NOT want to install ISC DHCP on a server that is in a network already running another DHCP server, funky results will occur.

The last thing to do (for now) is to ensure that tftpd, and DHCPd will start at boot time. You can achieve this a number of ways. I just use the command ntsysv which is included with all RedHat Derivitive distributions of Linux.

NOTE: I will assume you are using MS-DOS bootable media, and not PC-DOS, FreeDOS or any other kind of DOS.

Now onto WinImage; our specific example of Norton Ghost 8.0 creates either 2 1.44MB floppy disks, or a CD-ROM ISO for you to boot off of. Create a folder on your Windows machine called “Ghost” or whatever else you prefer, and copy the contents of both floppy disks into this folder. You need to edit the AUTOEXEC.BAT file in your “Ghost” folder. It should look like this:

@echo off
SET TZ=GHO+05:00
prompt $p$g
\net\netbind.com
MOUSE.COM
cd \ghost
GHOST.EXE -RB -SURE -QUIET
goto END
:END

I will note that you may want to modify your GHOST.EXE command-line as mine is set to automatically reboot, and not bother me about every little detail in the GhostCast Client.

NOTE: In order to do the next step, WinImage must be running in professional mode.

At this point you should have a Ghost folder which is roughly 1.7MB in size. Load up WinImage and tell it to create a 2.88MB floppy image. Insert the contents of the “Ghost” folder into this image and click on Image > Boot Sector Properties; Click on Windows 95/98 to ensure that this image is bootable. Save the image as whatever you prefer to call it, and exit WinImage. Copy the newly created image into the /tftpboot folder on your PXE server.

Now we must create a pxelinux configuration file. For now, we will just setup a default configuration file (which means that every DHCP client will recieve the same image from pxelinux).

cd /tftpboot/pxelinux.cfg

Create a file called default, mine looks like this:

label Ghost
kernel memdisk
append initrd=ghost.img

I am assuming that you have created a file called ghost.img in your /tftpboot folder, you will also need to copy the memdisk binary. Memdisk is software that allows you to boot just about any sort of disk image (as long as it is valid, and bootable).

cp /usr/lib/syslinux/memdisk /tftpboot

Ensure that dhcpd and tftp-server are running on your server machine.

service restart dhcpd

Note: Generally TFTP daemons run under inetd, or xinetd; so you will need to make sure that those helper daemons are allowing tftpd to run on your server. The configuration file for inetd is /etc/inetd.conf, and the configuration directory for xinetd is generally /etc/xinetd.d I wont spend too much time worrying about the configuration of inetd.conf, as most modern linux systems use xinetd.

The xinetd.d folder holds multiple configuration files; all of which you can enable or disable services with. You may need to edit /etc/xinetd.d/tftp to look something like this:

service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot -r blksize

Now comes the fun part, testing this bad boy out. Get that old Pentium 3 1GHz out of your garage, and set it up for network booting. Then Fire it up, if Norton Ghost’s DOS client or whatever else you want to network boot pops up on your screen you’ve done it. If not, post in the forums, and we’ll get you straightened out.

Enjoy your Network Booting Ghost machine!

Quick and dirty load balancing using Extreme Networks switches

Monday, August 7th, 2006

This article explores how to achieve simple server load balancing using inexpensive and readily available extreme networks switches.

Most Extreme Networks switches are capable of server load balancing, and Extreme Networks switches are available for next to nothing on eBay. There is a very large limitation to server load balancing on Extreme switches however; they absolutely will not load balance if there is a layer3 switch between the switch and the servers (i.e. if you have a firewall in between the Extreme switch, and your servers…)

Keeping this limitation in mind, Extreme Networks offers a very robust set of server load balancing options similar to dedicated load balancing hardware (Foundry ServerIron/ServerIron XL)

Here is a brief summary of how to SLB on Extreme Networks switches.

Below is a list of commands, under there is a line by line

#Here we create the VLAN that your load balanced servers will reside in. We assume that your switches’s IP is 10.1.5.1, and that your servers are on ports 2-3

create vlan lbservers
conf lbservers ipaddress 10.1.5.1/29
conf lbservers add port 2 untag
conf lbservers add port 3 untag
enable ipf

#Create the Server load balancing pool and add the real servers.

create slb pool lbpool1 lb-method round-robin
configure slb pool lbpool1 add 10.1.5.2 80
configure slb pool lbpool1 add 10.1.5.3 80

#Create the virtual server, assign real server pool to virtual server

create slb vip lbvip1 pool lbpool1 mode translation 10.1.5.4 80

#Set the server load balancing type, enable server load balancing, enable ip forwarding.

conf lbservers slb-type server
enable slb
enable ipf

#Substitute gateway for the name of your VLAN which connects upstream

conf gateway slb-type client

#There you have it, a very simple server load balancing configuration for Extreme Networks switches.

Enjoy making your purple dinosaur do new tricks! (dance Barney dance!)

-Drew