We have a Dell PowerEdge 2450 laying around doing nothing, and my friend asked to set up a server for him so he has a dedicated system to do some Drupal work. I said, no problem….. Boy was I in for it.
I downloaded the Server ISO and burned it. After upgrading the RAM from 1GB to 2GB and setting up the 3 x 18GB 10k rpm SCSI disks in a RAID 5, I booted from the fresh disc and the Ubuntu installer came up and when it dropped into the Debian base installation and tried to load components from CD, it would get stuck about 17% of the way through saying it could not read the CD-ROM any longer. So, I tried burning another copy…. Same thing.
OK, this system is pretty old, so I swap out the older CD-ROM for a tray-load DVD-ROM. Same thing, but at 21%. Grrr.
I try a THIRD CD burn in a different burner and still halts at 21%. I pop into the psuedo-shell in the Installer and try to do a ls on the /cdrom directory. I get some Input/Output error lines for docs, isolinux and some other items, but do get some output lines from that directory….
OK, now I’m wondering if my ISO didn’t perhaps get corrupted in the initial download. Unfortunately, Ubuntu does NOT provide MD5 checsums on their ISO images at least not directly on their website where you download it.
Let’s ask the Google. Apparently others have had the same issue since at least the 7.0 series. The Minimal CD works, but there doesn’t seem to be a way to install into the Server version from that.
I finally find a post (see link below) where success was had by using a SECOND copy of the Installer in a USB connected CD-ROM drive. The system boots off the internal CD but pulls all the material off the CD on the USB drive.
It is finishing the install as I type this.
Wow, what a Rabbit-hole!
Just another example of: “Linux is Free if you’re time is worth nothing”
Posted by Brian Blood as Hardware, Linux, Servers at 9:05 PM UTC
No Comments »
This is a continuation of the saga of helping a customer of ours with their MySQL on Windows issues.
The basic premise is that MySQL 5 running under Windows has problems with large numbers of connections/open files.
We initially presented our client with 2 choices for solving their problem:
- Setup MySQL on a different server running Linux
- Move their database backend from MySQL to Microsoft SQL Server
Option 1 would require a non-trivial capital outlay and time to setup and migrate the data over
Option 2 held more interest for them as a longer term solution as they were interested in some of the powerful reporting and analysis tools. However, the server that all of this was running on turned out to present a problem in the following way:
The system is a Dell PowerEdge 2950 with dual dual-core Xeons (with HyperThreading enabled, resulting in 8 logical cpus), 8GB RAM and running Windows 2003 Server x64. For a general ballpark estimate of pricing for MS SQL Server, I went to the Dell website and configured a similar machine and went to select a SQL Server as an add-on. Due to the way that Microsoft prices SQL Server for a web environment, you must license it for each processor you have installed in your server. A dual-processor licensed SQL Server 2005 running under Windows x64 turned out to be in excess of $14,000 on that page.
Needless to say, the customer had a bit of sticker shock. Not only would they have to plop down FOURTEEN grand, they would still need man-hours to work out kinks in transitioning the backend of the app from MySQL. Getting a fully loaded separate server for half that cost running Linux/MySQL was looking more attractive.
I was chatting with a friend about the customers dilemma and he had a brilliant suggestion: Run a Linux instance under VMWare on the existing hardware.
I broached the idea with the client and they were game to give it a shot. The server was at this point extremely underutilized and was only limited by the specific software implementations. They were already running MySQL here anyway, so putting a different wrapper around it in order to escape those limits was worth investigating.
The server needed some more disk space so they ordered 6 more of the 146GB 2.5″ SAS drive modules like the 2 that were already installed in a mirrored pair. These are great little devices for getting a decent number of spindles into a database server.
While they did that I installed the latest Release Candidate of VMWare Server 2.0 and went about setting up a Debian based Linux install with the latest MySQL 5.0 binary available. During testing we had some interesting processor affinity issues for the VM environment and after a very good experience and excellent responses in the VMWare community forums, I tweaked the config to have that VirtualMachine attach itself to processors 5-8 which correspond to all of the logical cpus on the second socket. This left the first socket’s worth of cpus for OS and IIS/ASP usage. Doing this would help avoid the cache issues that occur with multi-cpu systems and multi-threaded processes.
I ended up configuring the VM for 3.5GB RAM, 2 processors and tweaking the MySQL config to make good use of those resources for their INNOdb based tables.
The system has been running very reliably for over 2 months and is making very good use of the resources on that system. Load Average in the VM stays well under 1.0 and the cpus in the Windows system are easily handling all the different loads.
Overall I spent probably 8-10 hours installing and tweaking the config and helping them migrate their data. This was much less expensive to the other options and they got to make use of their existing hardware and software configurations.
A very positive experience and outcome.
Posted by Brian Blood as Database, Hardware, Linux, MySQL, Servers at 2:41 PM UTC
No Comments »
In our previous adventures with Mac Minis as “blade” servers, I thought we might try installing Ubuntu/Debian on an Intel MacMini and seeing how the system performed against an OS X client based system.
Well, we did that and about a week later we wiped the machine and imaged off one of the other Minis and set it back up under OS X.
We had one of our techs scour all he could find on the net about installing Linux on an Intel MacMini and the biggest hurdle was getting something working in the EFI realm.
We ended up using rEFIt, a project on sourceforge, to allow us to dual boot into either Debian or Tiger. This had some issues, but in the end it worked out ok.
The USB Ethernet adapter also worked rather well right out of the box.
No, the real kicker was the on-board gigabit ethernet which is used on the backside primarily for database access. The Mini uses the Yukon based chipset for it’s GigE port and and this combination with the default ethernet driver installed by Debian induces a flow-control hang under certain loads.
Marcus Bointon hinted as much in comment #6 to my original article and so when the Debian Mini developed problems communication over that interface, I was pretty sure where to look.
Debian by default picks the “sky2″ driver for that PHY and it wasn’t cutting the mustard. Apparently this bug has been around for a couple of years (the chipset is also used on some other system boards) and the “workaround” is to recompile a different ethernet driver into the kernel and it solves the issue. Since running Debian on this system was merely a trial, we decided to punt instead of sinking more time in tinkering with it.
Under Debian, the Mini did actually perform about 10% better than when it was running Tiger. Ultimately, the OS turned out to not be the biggest factor in getting more performance out of the load balanced system as a whole. Tuning Apache and making some other improvements to the web application proved to be far more useful.
Posted by Brian Blood as Hardware, Linux, Servers at 11:57 PM UTC
No Comments »
Having built a couple of other Debian servers using software RAID 1, but not recalling exactly how I got it to work, I decided to actually document the results here.
So I needed to build up a system that we could dump really large drives into for some customers so they can do offsite backups. We had started doing this using FireWire drives attached to a G4 running Panther server, but it started to get a bit messy and sometimes FireWire busses can be a bit finicky.
We had a rackmount system that had 8 hot swap IDE bays in it, powered by an old AMD board with 6 PCI slots and it was perfect for what we needed. We had it at the colo for doing backups there, but the RAID card had some issues, so we had pulled it and it was sitting on a shelf for the past year.
I took a SATA PCI card (fake raid, don’t get me started) and mounted two 160GB SATA drives (that we had pulled from two different PowerMac G5s) into one of the internal drive cages. This gave me 2 nice big disks to create my boot system with.
Booting from a RC1 biz card install of Debian Etch, I got to the Partition Disks section of the install. This is the really tricky part because if you don’t do things in the right order, the partioner will not be able to set things up correctly and produce something you can actually install onto.
Here is the basic outline of what I ended up with in terms of partitions:
/boot
/
/swap
however!!! all mounts are not created the same.
so, let’s start with our two physical disks, sda and sdb
on each of these I created two actual partitions:
- one small partition at the beginning (around 64MB) that will be used for the boot mount
- the rest of the disk that will be used for everything else
so I ended up with 4 partitions: sda1, sda2, sdb1 and sdb2. All 4 of these partitions are set to have a type to be used for software raid
next I created 2 new software raid1 devices using the corresponding partitions on each disk.
- The first raid1 disk I formatted as ext3 and designate it’s mount as /boot. Nothing more needs to done with this disk.
- The second raid1 disk I do NOT format, but designate it as to be used for the Logical Volume Manager (LVM) All remaining partitions will be created from this device.
Proceeding into the LVM screens I did the following:
- I create a single Logical Volume Group using the single raid1 device I made from the sda2 and sdb2 partitions.
- I then created two Logical Volumes from this one LVG: sys (most of the disk) and swap (the ending 8GB of space)
- I formatted the sys LV as ext3 and designated it to be the root mount point /
- I designated the swap LV as (surprise) swap
Once this tree of raid1 devices and LVG/LVs were in place…. I had no problem installing Debian and continuing on with setting up my big drive box. I will use PureFTPd and netatalk (for reasons I will explain in another article) for server side daemons.
Posted by Brian Blood as Linux, Servers at 10:17 PM UTC
No Comments »