As I've posted, I'm in the process of redoing Eskimo's infrastructure, moving away from UltraSparc machines and to Intel based machines.
Right now only the main file server is Intel based (Xeon 32 bit).
I'm putting together a new box (hope to have all the components here by Monday) that will be an i7-2600 (not 2600k) quad core 3.4 GHz CPU,
32GB RAM, and two drives, a Velociraptor 1TB drive for mail spool, and another 2TB drive that will hold home directories and system files.
I'm going to virtualize this machine into a number of virtual machines, a couple of 8GB machines that will handle mail and web respectively,
and a number of smaller machines for other functions. These will mostly be running CentOS 6.2 Linux.
I've played with both Xen and Qemu/KVM and plan to go with the latter. From a standpoint of performance, I don't see a lot of difference
between the two, but Qemu/KVM is a lot more flexible, easier to configure, and portable. The user files are going to be hosted on a physical
machine and exported via NFS on that machine, and the mail server, although it will be virtualized, the spool which has heavy I/O will be on
a physical real partition. Actually, it's going to have an entire drive save for some boot partitions, dedicated to it and it will be a 10k RPM
With the web server, I am wanting to equip it to be capable of just about every server-side thing possible, but I may run a separate server for
mono .net applications because mono doesn't play well with anything else, in the sense that all traffic needs to be handed off to it and then it
becomes a bottleneck for everything else and that is inconsistent with my goals for Eskimo.
I have five goals, to be a service that if anyone goes anywhere else, it's gonna be slower there. To be a service where if anyone goes anywhere
else, they are going to lose some capability, and to be a service where if anyone goes anywhere else the support is going to be worse, and to be
a service where if someone goes anywhere else it's going to be less secure and stable. And then to do all of that in a way that is cost competitive.
Presently, we are faster than 58% of what's on the net. Not bad considering the machines are 15 years old and PHP is launched via CGI so that
code executes with each users UID. That prevents one persons code flaws from compromising other peoples websites.
That's not where I want to be though, I want to be in the upper 1% area, and maybe that's not possible with a 100mb/s connection but I suspect
it that most of the time it takes web pages to load is not wire speed related.
Anyway, the real reason for this post is to solicit things people would like to be included that perhaps I hadn't thought of and to solicit help in
finding solutions to provide certain capabilities. Right now I'm thinking about the following server side capabilities:
ASP .net - Planning to implement using Mono, however probably on a separate server.
CSP - Server Side ANSI C, haven't found an implementation for this yet, if you know if any please let me know.
Cold Fusion - Looking at Railo to implement CFML.
Groovy / Java / Grails - Still researching these, I've had request for Java servlets in the past.
There are a lot of pieces that go with all of these things and how well and if they'll play together remains to be seen. But I'd also like to look into
anything else people might want at this point. I'm pretty much avoiding proprietary things like Lotus Domino, Websphere, WebDNA, etc, where open
source implementations do not exist. The "doing it all cost effectively" and "securely" both figure into that decision. If it's proprietary it's probably
not going to be cost-effective, and if I don't have the source security is also an issue since I can't see what it's doing.
This new server will also be SSL enabled. I am planning on a 2.4.x server (presently playing with 2.4.6), however, I may go with 2.2 if I can't
find version so of all the necessary modules to work with 2.4.x.
I'd really appreciate any input now, while I'm in the process of building it, so I can get everything in there people might want.