News and Reviews > Official Announcements

Preparing for a new master DonationCoder server

(1/7) > >>

mouser:
DC server admin Gothi[c] and I have been discussing the possibility of moving to a new server for quite some time, and it looks like we are getting ready to pull the trigger and do it.
We still have more research to do and more decisions to make, so we thought we would start a thread where people could chime in.

Let me tell you the starting point for how we are looking at this.

First, our current setup is as follows:
We have a $279/month dedicated main server, hosted by SoftLayer; they are very reliable and very good, but on the high price side of things.  It's a Dual Processor Quad Core Xeon 5430.
We have a $100/month dedicated member server, hosted by netdepot; we've had some service issues with them but they have been really good about price and let you buy down up front costs to reduce monthly costs.

Having two servers has been important in letting us keep the main server fast and secure, and putting less secure and lower priority stuff on the member server.

But Gothi[c] has been really pleased with the new VMWare operating system setups that can be done on servers now, which allow you to run multiple virtual servers with their own operating systems, completely and securely isolated from one another.

And we have some other things we'd like to do with a new server setup, to improve security/scalability, and to make new projects easier in the future (such as creating a new virtual machine for secure hosting of experimental projects, etc.).

SO.. our current thinking is to transition from these two servers, to a new single server, running multiple virtual machine operating systems, and the thing we are debating now is the best way to organize the one master server into multiple virtual machines..

Gothi[c]:
So, there's a few ways we can go about this....

One suggestion:

* main dc server http on a vm (minus mail)
* dcwing member server on a vm (minus mail)
* vm for main dc email
* vm for member server email
* vm for newsletter sending
* (optional - vm for sql )
* vm for commercial project hosting

The main reasoning behind putting the newsletter on it's own vm (and more importantly IP) is so that should we ever unjustly be considered spammers due to the high volume mail of the newsletter and end up on some blacklist, the mail forum registration mails won't stop working (ie end up in people's junk mailboxes). This vm wouldn't have to run all the time, only during newsletter sending time.

The reasoning for seperating SQL on a separate server is security and scalability. A compromised sql server won't touch the main server's files. (Same reason why email would be separate), it also allows us to tune the OS setup towards the specific task. (eg, mail would have a larger /var partition for the mail queue, and perhaps a filesystem that performs better with lots of smaller files)

Currently we already have MySQL and Apache isolated on the member server using BSD jails. It works but I feel there is some performance hit due to the need for NAT in pf. Having separate vm's would be a much cleaner solution.

There's many other ways we could go at this...
The mail vm's could all be diskless OS'es with a master server so that 1 OS upgrade migrates to all the vm's automatically for example. (It would also save a lot of drive space). But then the problem of course is that if the master server goes down, all the nodes will too. (We could put them on a NAS if we can afford it, though that's up in the air right now)

If any one has good ideas on what services to separate in which vm's lets hear them. It's more fun if we can involve everyone in building our new home :)

Gothi[c]:
So, post more graphs like this: ;)

[ Invalid Attachment ]

worstje:
It's always good to see movement in the serverpark to know stuff is not left to bitrot simply because it works. :)

However, I feel it warrants saying - you put a lot of focus on the 'what if something breaks' department. Whereas before you had a pair of servers on two different locations (if I understand it properly), now you intend to scale it all into a single physical machine. Suppose some mechanical doodah goes down the crapper, how easily can you move one of those VMs to another physical machine? (That is supposed to be one of the strengths in a VM, after all, right?)

Shades:
@ worstje:
Movability will be dictated by the backup plan that is in use or will be used. Besides that, there could be a redundant server there that is ready to take over.

Now I do agree with worstje that DC is putting all off Cody's eggs in one basket with this scenario.

If it was me I would consider getting two PC's with slightly lighter hardware spec (which normally drops the price of them quite a bit) and divide the load. In case one of them craps out there is always the other PC that can take over, while the 'crapper' can be repaired/replaced.

From the graphic I understand that the load could easily be 'smeared' over two PC's. Now it is not known to me if DC has their own dedicated server parked with either ISP or that they could buy the one that they are using now. Anyway, maybe it is an idea to use that one as the backup and buy the new PC as specified by Gothi[c].

That way everybody can be happy and confident that the essence of DC website always will be served to the community (as long as the electrical grid supplies the power of course).

Navigation

[0] Message Index

[#] Next page