Player Features and Ideas Discussion

Then you have to issue a roll-back patch to the clients too.

That should be utterly trivial.

There should be backup copies of every client version released. And there *certainly* should be copies of the latest few.

Issueing a "new" client that's a copy of an old client really shouldn't be difficult.

you either over your head here OR you should be working for CCP my money is on the first (no offence)

but you can`t offer real solutions without knowing the infra structure i am no n00b with computers but i aint an expert either but i am pretty sure that what i say is correct, if not feel free to correct me without assumptions.

So, a tangental comment, on a programming board, was that they had implemented multi-core support for the multi-threaded python that eve runs on about 6 months ago, and then there was talk of a "massive, real world, high-uptime" implementation to follow. Bets that it was EVE that the programming board was talking about, and that the bit that broke is related to multi-core support for the python, thus making it
A: a deeply technical issue
B: Deep wizardry if it broke at the compiler level
C: breaking any backups from before this was implemented
D: making most of this WMG about what went wrong uninformed and useless, even if someone is correct

Please do tell op how a vm is better than a dedicated physical box.

Keep in mind the following:


You can build a physical that matches or exceeds the specs on an esx host (will assume vm esx system, can be windows based hypervisor),

In esx you have to limit the resources to the VM. Ideally you want something not used as a buffer. At 75% max utilization you should be getting leery about load use.


VM does not offset redundancy costs. that fail over esx host( or hosts) has to match and/or exceed the "primary". Primary being the one you prefer to host VM's from. I can move my vm's to esx hosts at will....we just like to see them on preferred hosts when we vm vsphere in. So its actually a few monster esx host boxes.


Snapshots are not backups......they are more convenient than say tape but, they have not replaced tape/drive based dedicated backup solutuions. Nice to have yes....but tape (or say disk based stuff like EMC has been trying to pitch to us for a while now....wish we had the money for it tbh) is still king for backup.

If snapshot used depending on how long they are stale you are now replaying transact logs to get the database up to date. With sql restores this can be the time killer. I can get backup off even tape decent. Its replays that can be fun.

Somewhere in past reads CCP hinted/mentioned that each system runs on a particular server but not all systems are on one server. This would suggest a cluster of servers with each server managing its own world of Eve and its own work load.

Assuming so could/would mean that each users connection could terminate at a front end server. Creating a multi-tiered architecture model. As the user goes from one system to another the front end client connection is redirected (handed off) to the other server. I'm going to presume that Eve is a multi-tiered model rather than a monolithic model.

With that said. That would mean that the multiple front end servers could be actually behind some load balancers (e.g F5 BIG-IP or alike) Linux does have a built-in daemon that could be enabled so anything goes depending on the applications requirement.

People throw the virtualization word around like its so simple. It's true that the most advanced hypervisor is VMware, but you need to different versions to take advantage of the HA and/or the intelligent modules. Snapshot give you the ability to role back within 30 seconds, far faster than reloading data from spinning disk or tape. So there's some great benefits.

What has to be considered is the underlying infrastructure, hypervisor is specifically designed for servers ideally with as least amount of vCPU allocated as possible - so 1-2 vCPU is the best. in this case less is more! Why because hypervisor has to wait until the allocated cpu's are ideal before a query can be addressed into the cpu. So when an server with apps on a physical server can have up to 24 proc this is not ideal in the VM world. and in 90% of times the sys admin will drop the proc count to less than 8 to get optimal performance, I've even seen it go below 4. Again its environmental and a great deal of experimentation is usually required. Cardinal rule number one is never ever allocate to one vm the total number of physical CPU's on the hardware. Mainstream servers are at 24 or 36 CPU's today in the Intel/AMD Chipset.

While people are guessing what's going on, we really don't have a friggen clue as what I've just mentioned is not even scratching the iceberg (no pan intended for Iceland ).

I'm not even going to add to this the software code and the gazillion customisations that can be had. The mind boggles in astonishment to what could or could not be the RCA (root cause affect) of what we just witnessed in the last 16 hours or so.

What happens if the rollback procedures fail?

Overall this is the same crap as was posted here
https://forums.eveonline.com/default.aspx?g=posts&t=434766&find=unread

It all comes down to a bunch of people who have no clue how CCP has any of this set up. what software / hardware ect CCP uses yet they are some kind og computer gods, or they read something somewhere on the internet (see link above) and they think it will be better.

As in the topic linked how about we leave the ideas on solving problems to those who actually know how all of this is set up and people that work with it every day/.

*facepalms at OP*

How could you make assumptions without having internal knowledge?

The devs are D-, the server techs are people that don't see the code anymore.

The idea doesn't work. Tranc is a room full of super computers that change configuration every night; running a VM on that would be madness and I don't know how it would help.