Otaking 2.0

From otaking wiki

Revision as of 09:00, 13 October 2007; view current revision
←Older revision | Newer revision→

Plans for otaking 2.0

1 Hardware
2 Software
- 2.1 Main Goal
- 2.2 Fallback
3 Concept
4 Virtual Machines
- 4.1 Additional services
- 4.2 Storage
5 VMware tweaks
6 VMware discussion forum
- 6.1 Interesting topics
7 Links
- 7.1 VMware
- 7.2 Tom's Hardware

Hardware

Hardware plans have changed yet again, and it's close to being final. This time the focus is on relatively low power consumption.

Pre-existing hardware

I have a bunch of old drives that are starting to tap out. I have decided to put them out of their misery rather than trying to squeeze the last few months out of them.

What I need

My main requirement for a new server is data redundancy. I'm tired of unreliable hard drives that fail with little or no prior indication. The new server's system drives will therefore be set up as a two disk raid 1 array. Most likely software raid.

Low purchase and running cost is also of concern.

This has been my most recent starting point when deciding what hardware I should buy.

Planned purchases

Case

Chieftec Mesh Fulltower or Chieftec Mesh Miditower with a 400W PSU included.

I will require two 120mm fans and three to five 92mm fans as well as a fan controller with at least 4 channels to go with them. Maybe some filters as well.

Motherboard

Asus M2NBP-VM or M2NPV-VM (they seem to be fairly equal) with the AM2 socket and ECC memory support.

CPU

AMD Athlon X2 BE-2350.

RAM

I believe 2 GB of DDR2 ECC RAM of a decent brand will be enough.

Graphics card

I won't be needing one with the current choice of motherboard. It comes with integrated graphics.

Storage

2x 320 GB SATA HDDs (Western Digital RE, RE=Raid Edition with 5 year warranty and other goodies). These will be for my system drive in a software RAID 1 array.

Eventually I will consider getting the following as well:

4x 500 GB Western Digital RE2 for additional storage in a software RAID 5 array.

Software

Main Goal

Host OS: CentOS 5 (based on Red Hat Enterprise Linux)

VMware Server for Linux

I want to attempt this possible solution since this will give me more freedom. It will be much more dynamic to use VM machines than having just one main OS directly on top of the hardware. It allows for more experimentation, and easier backup.

Fallback

Host OS: FreeBSD 6.x (or 7)

If the VMware solution isn't feasible I will fall back on having FreeBSD installed directly. If I have to go with this idea I will explore FreeBSD compatible virtual machine server software.

Concept

Minimal host OS running multiple guest OSes with VMware Server.

Virtual Machines

A short list of possible configurations of virtual machines. Each VM has some overhead in terms of RAM usage which limits the number of VMs I can run at one time. Possible overhead (up to 54 MB for a VM allocated up to 512 MB RAM) is not included in resource proposal per VM.

(This list was composed when I was aiming for 4 GB of RAM and more CPU power. It will be updated in time, but for now it stays.)

	Description	Guest OS	Service(s)	Resource proposal	Main storage	Comment
VM 1	Firewall/ router/ port forwarding	Free- or OpenBSD	ipfw with dummynets(?)	~128-256 MB RAM	Configuration saved within VMfs
VM 2	HTTP/FTP/radio/mail etc.	FreeBSD	Apache 2.x PureFTPd(?)	~256-512 MB RAM	Files accessed via NAS(?)
VM 3	DB/storage server	FreeBSD	MySQL 5.x, SVN, samba	~256-512 MB RAM	DB saved within VMware virtual disk Misc storage t.b.d.	Current database size ~120 MB
VM 4	minikai	Windows (2k?)	MSN, IRC, ICQ, Jabber, etc.	~512-768 MB RAM	Files saved within VMware virtual disk
VM 5	Misc Windows client	Windows (2k?)	DC/BT etc.	~512-768 MB RAM	Storage access to VM 3 via VM 1
Summary				~1.6-2.8 GB RAM / 4 GB

Additional services

Some form of combined user database to connect mail, FTP and storage. LDAP?

Storage

Different ways to manage VM/data storage. The easiest way to share access to data is to utilize the storage VM server.

One idea is to store the information in the same VMware virtual disk as the guest OS. This could work well enough when the required storage space is low.

A better idea is to store the data in a separate VMware virtual disk from the guest OS for easy backup. In the case of large storage requirements, like for the NAS server, this is a much better idea than the previous since it separates the OS from the data.

A third idea, mainly for the NAS server's more permanent storage of larger files, is to mount one or more partitions/devices raw. You wouldn't need to have data stored in VMware virtual disk files on such drives, which increases portability and access from outside of the VM if necessary.