New Game Server Progress

Kuros said:

Problems that were very prevalent in the past. But if you want to jam a bunch of servers on a mirroring set be my guest. Since I don’t know anything I am going to stop posting in these threads. I have no experience running gaming servers.

Don’t do that, we all know you do have experience running a gaming server. Make your point about why it is better to do it your way, “Stop being a negative nancy”.

I guess since this is a public thread I will explain in more detail for the less computer savvy. Kip and Nickname *should* already know this. What happened in the past was that the Virtual Machines (we would be substituting additional servers for VMs, so again you can’t call this argument invalid because there are no VMs) would demand a huge chunk of read or write space. Typical I/O on the drives is relatively low and it streams along reading and writing data in a pretty quick fashion because of it’s striping capabilities. The idea behind a stripe is that it’s faster for 2 hard drives to store half a file at the same time than one drive to store the whole thing at one time. (That’s simplified but basically how it works, and the theory makes perfect sense.) The setup they are proposing will read/write an ENTIRE file or request to EACH disk. While this does give us data redundancy it’s pretty *edited*ing slow. Anyways, back to the VMs. What would happen is that the VMs (or new servers in our case) would request a larger than ordinary chunk of read/write. Then what happens is that the disk cannot fulfill that request immediately so it hangs up other read/writes and queues them up so that it can process the large request. It creates sort of a bottleneck until the large write (up to 200GB/s I’ve seen) gets shoved through, then it can continue on with the requests that it had to queue up until it catches back up. So what happens when that fat file blocks up the proverbial bottle? You get lag spikes and poor shot registration because a lot of that data getting queued up is your 1.6 and CSS server.

That in a nutshell, is the problem with going with a mirroring set over a striping one. While a stripe may require occasional backups, it would be worth the gain in performance.

EDIT 1: I hope dear Bitey, this fulfills your request.

EDIT 2: Just thought of another problem which would be the way Windows Server likes to page every *edited*ing thing ever rather than use the 16GB of RAM. While Linux server would eliminate this I am 100% against putting Linux server on the new box. (Even being a Linux user myself). It’s simply hit or miss on whether or not our successors will be able to use it and it’s minimal teaching them to do things in Windows Server.

excellent wright up

Nickname said:

Additional comments:

 

-RAID1 performance is virtually identical to that of a single drive setup. Thousands of benchmarks online will support that fact so I am not going to post an arbitraty one here but think about it: all it does is the raid controller mirrors to the second drive whatever is done on the first drive. That second drive doesn’t impact performance at all.

 

-the VMs caused such disk issues because they had lots of small disk writes… write performance of small files of RAID 5 is its achilles heel, so that likely will account for the issue there.

I never said Raid 1 was slower than a single disk access. I said it was slower than 5 and 0. What’s the benefit of going 1 over 0? You can make backups (and should be making them). So I don’t see redundancy being a problem.

Nickname said:

I know you didnt. I just said that for others who aren’t you/me/kip.

As far as the redundancy… if we RAID 0 and a drive dies… we have to wait to get a replacement before we can continue on. with RAID 1 if the drive dies we can keep going while we wait for the replacement.

 

But yes, we should still be making backups in other places.

You can continue on with the single drive as far as that goes. Failure rates aren’t uber high. Also, is it true hardware raid or fake raid? Onboard=fakeraid.

Nickname said:

its real raid with 128mb ram. And no you couldnt continue on with the single drive unless your formatted and you would have to format again when you introduced the second drive if you use raid 0.

Nice on the real raid and yes that’s correct on the double format. Guess we’ll just have to see how it goes.

MasterP said:

Why on earth would you recommend not having parity on a production server?

It’s processing a metric *edited*ton of data on the fly. If it were like…a db server or exchange server or app server then no *edited*ing way. But it’s not. It’s actually permanently storing a very small amount of data that could easily be recovered.

All you need is one back up every time something significantly changes. The only thing you actually lose is logs.

Honestly at this point I’m just arguing to be arguing. I think the upgrade to 15k disks make this a moot point. I’m 99.999% sure that Trons disks are 10k.

Kuros said:

EDIT 1: I hope dear Bitey, this fulfills your request.

Lol, yes it does, love you too.

i can donate 1.01 for that *edited* if you need lulz

dood that makes it less than 4g now, CHEAP!!

forget about the CPU we have up there…put this on…

http://www.insidetech.com/news/articles/48…alem-ex-servers

MasterP said:

This whole issue is going to come up again in June and I’ll try (again)

Are you going to be at western next semester? doing a masters pr0gram or something

yeah i highly doubt anythings going to happen over the summer. Maybe shoot them a friendly reminder email, hey we are still alive sorta thing, set up a meeting date for the first of the semester b4 things get to hectic. Thats the goog thing about summer its slow, they might be able to place more thought / time into it.

No idea what I’m talking about so…