Ken Gunderson wrote: ... > The application in this case is a routing firewall/proxy server for a 3 > legged network configuration. Resources to implement a carp setup are > not available. The objective for the system: > > 1) to be as self healing as possible > 2) minimize downtime resulting from this single point of failure failing > 3) maximiz capability for remote system management > 4) minimizing requrement for assistance from on site personnel. > > /home, /tmp and /var/tmp are inconsequential. No users on this system. > But the system will be doing smtp relaying and in the unlikely event > some malicious type was able to induce obsd to crash I'd like to have > the packets logged... Logging to remote machine is good practice but not > an option at present. So we've got a large /var on this puppy. Hence > the long wait. Otherwise if just for perimeter firewall/router a > diskless setup would probably be best. > > I've done some testing w/the /etc/rc backgound parity hack and the box > comes up after a hard failure in about 1/2 hour. Which isn't too bad > compared to the 1.5 -2 hours otherwise. > > For the sake of experimentation the raid conf is presently: > > 512M / mirror > 2048M swap stripped > couple hundred gigs mirrored for everything else. > > Thanks for your insights. Appreciate the constructive input.
ooo...firewall. That should be REALLY easy. :) (oops. just went back and re-read it and noticed the "/proxy" part. That skews the rest of this. kinda. Well, consider the suggestions anyway...) You shouldn't end up mirroring more than about 350MB. Seriously. (ok, MAYBE 512MB.) / 70M /usr 140M /home 30M /var 30M /tmp 20M NO swap. Firewalls shouldn't swap. PF won't swap, anyway. you end up installing JUST base38.tgz, etc38.tgz, and bsd.rd Yes, the machine ends up being not self-sufficient, but that's pretty much true of most RAIDframe systems -- you have to build the kernel on another machine anyway. If you want to have some non-mirrored, unmounted partitions for storing upgrade files on or other stuff, fine...but DON'T MIRROR THE REST OF YOUR DISK. [I don't think the proxy cache would need to be mirrored. yes, you would end up rebuilding it if you lose a disk, but that's probably the least of your problems] OR..consider a non-RAIDframe design I've been using lately: Two disks, say wd0 and wd1 First disk can be small. Partition it up as small as comfortable. Second disk (wd1) is bigger (40G, maybe) and mirrors..er..duplicates the partitioning of the first disk, but also has a huge "/backup" partition, which is mounted as part of rc.local, NOT fstab. Nightly, the ALTROOT process duplicates your / partition (and thus, your /etc files). /etc/daily.local includes a step which makes a .tgz file holding /var and /etc contents on /backup, with a date code (i.e., backup2005-10-22.tgz). weekly.local dumps/restores the rest of wd0's partitions over to wd1, and make sure you have the bootloader installed on wd1 properly. NOW...you have rotated backups (sorta...they still are on the same machine, so far from ideal, but better than what you are doing at the moment, I bet! :), two disks that could each do the job of running the machine, and a back door if you do an upgrade that goes poorly. I've done this on two different kinds of machines so far, both, it turns out, could boot from the second disk if I unplugged the primary. SO, if the primary fails completely, the system still comes up. Worst case, if the primary fails but not completely, you have to remove it, but don't have to rejumper the second drive, however, you HAVE to verify your machine's BIOS will do this properly. BTW: some of those cheap, pseudo-RAID cards may help here, as the BIOSs are generally designed to boot from the second channel if the first is unbootable. The simplicity factor on this one is a big selling point for me. :) I'm doing this with a few DNS servers at our office, they have a 40G drive as the second drive. The /backup partition has been collecting over two months of backup*.tgz files and still hasn't passed 2% of the available disk space. One doesn't even have to worry about the /backup partition filling at that rate -- the machine will be replaced long before /backup filled...and I've got a copy of EVERY configuration the machine has ever had. Nick.
