These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Player Features and Ideas Discussion

 
  • Topic is locked indefinitely.
 

Soft Migration of systems to other nodes.
Author
Previous Topic Next Topic
1Robert McNamara1
Ministry of War
Amarr Empire
#1 - 2013-07-05 17:12:46 UTC
Yes, this is a feature idea in light of Z9pp and other system migration disasters. Let's keep the vitriol to a dull roar if possible.


A couple of times now systems with intense fights have been migrated accidentally. I can empathize with the problem as I've made similar mistakes in my own job. My employer hosts thousands of audio and video conferences for customers in the US. These conferences are hosted on million dollar appliances called MCUs. If I needed to move callers from one MCU to another or take an MCU down for maintenance I would have to end those active conferences. Outages kill business. I did it, and it sucked for much the same reasons (mis-click). Our business partners created a way for us to 'soft shut down' an MCU. It worked by flagging the MCU to stop taking new calls, and enter maintenance mode when all active calls were dropped.

CCP can do similar, but have the condition for migration be dependent on no aggression timers in system. CCP strikes the command 'soft migrate all systems in Centaur cluster to other nodes, exclude Q9PP-H'. Similar to the command given on the 4th, even with that dastardly typo. Only now the systems will not move to another node unless there are no aggression timers active. Leaving Z9PP-H alone along with any small fights happening in other systems nearby (which may also be strategically significant).

The hard move command still exists in the case of people gaming the system to keep performance low, but the first tool in the toolbox would be the soft-migration which only moved systems that had no aggression timers.
Swiftstrike1
Swiftstrike Incorporated
#2 - 2013-07-05 17:27:55 UTC
I'm not a tech person so please forgive me if I have misunderstood.

As far as I can tell: you are suggesting that if a given node has 10 systems on it and there is a big fight in one of them, the other 9 should be moved to other nodes instead of moving the 'fight system' to its own private node. The net result is the same except that the big fight ends up alone on a regular node instead of alone on a re-inforced node (which is what happens when they move the 1 instead of the 9). Performance is improved without interrupting the battle.

It sounds like a great idea, but surely this is already standard practice? +1 regardless.

Casual Incursion runner & Faction Warfare grunt, ex-Wormholer, ex-Nullbear.
1Robert McNamara1
Ministry of War
Amarr Empire
#3 - 2013-07-05 17:36:04 UTC
Swiftstrike1, Yes the system you describe is already in practice. It's what allowed the fight where multiple titans, supers, and capitols to die in Asakai to occur. Pretty awesome really.

In that fight, everyone was on point and those solar systems (the 9 without giant fights) were moved to other servers. that move disconnects all players in those solar systems but restores system function quickly and allows the 10th super fight system to continue.

The problem is that CCP has only 1 way to migrate systems, and it kills any PVP happening. On more than one occasion a system with a big fight was accidentally moved instead of the low-conflict solar systems. It's because the tool allows for the direct injection of human error and kills conflict.

My solution would augment the current system to have 1 step of checks and balances where a solar system that has any active PVP (aggression timers) holds firm on its current node until that PVP stops.

So in your example 10 systems on a node, soft move command is executed. There's a giant fight in the first system, and smaller engagements in 3 others. The 6 remaining systems would move to another server, then as fights cleared up in the other 3 systems they would get moved as well. All the while, the 1st giant fight system would carry on as if nothing were happening, experiencing better performance at a more gradual rate while still protecting the integrity of the PVP within the node.
Atum
Eclipse Industrials
Quantum Forge
#4 - 2013-07-05 17:42:02 UTC
I have a couple of ideas that may or may not work for CCP, but without knowing the underlying OS and hypervisor infrastructure, they could be nothing more than pipe dreams.
1Robert McNamara1
Ministry of War
Amarr Empire
#5 - 2013-07-05 17:44:03 UTC
Atum wrote:
I have a couple of ideas that may or may not work for CCP, but without knowing the underlying OS and hypervisor infrastructure, they could be nothing more than pipe dreams.


Put em out there man. I don't know how the underbelly of this stuff works either. Worst that can happen is they say 'no' or 'not possible'.
Atum
Eclipse Industrials
Quantum Forge
#6 - 2013-07-05 17:53:00 UTC
1Robert McNamara1 wrote:
Atum wrote:
I have a couple of ideas that may or may not work for CCP, but without knowing the underlying OS and hypervisor infrastructure, they could be nothing more than pipe dreams.


Put em out there man. I don't know how the underbelly of this stuff works either. Worst that can happen is they say 'no' or 'not possible'.

Most of it has to do with virtual machine migration, but whether or not that's possible (and worth developing beyond "This seems neat") depends greatly on their hypervisors (VMWare, Hyper-V, Xen, etc) and what interactions are possible between them and the OS underneath it (Windows 2008R2 maybe?) It's worth noting that VM migration is incredibly difficult to pull off in a live environment, but depending on how the thing is put together, and some of CCP's recent statements on how node remapping works, there could be a relatively (and I use that term only half-sarcastically) painless way to make it happen, that even with a typo wouldn't do anything more than put the whole show on "pause" for a minute or two (which us old-timers remember "fondly" anyways), followed by extreme TiDi, rather than dump the whole fight into the trash can.
Swiftstrike1
Swiftstrike Incorporated
#7 - 2013-07-05 18:03:29 UTC
Incidentally, this should probably be in this forum:

Eve Technology Lab

Casual Incursion runner & Faction Warfare grunt, ex-Wormholer, ex-Nullbear.
Atum
Eclipse Industrials
Quantum Forge
#8 - 2013-07-05 19:03:33 UTC
Swiftstrike1 wrote:
Incidentally, this should probably be in this forum:

Eve Technology Lab

Maybe, except the hover-over description says that's for third-party tools and apps (EFT, Eve-Mon, that sort of thing)
War Kitten
Panda McLegion
#9 - 2013-07-05 19:29:44 UTC
I'm not sure how your proposed system is different from what we have now. Even if there aren't any aggression timers going, the people in the systems that you shut down will still get disconnected. It's not any more seamless than it is now.

To equate to your MCU example, it would seem to me that a node would stop accepting people INTO the systems, and only migrate that system's node once the system was empty. And that just won't fly, especially if the system ends up being on a well-traveled pipe.

I don't judge people by their race, religion, color, size, age, gender, or ethnicity. I judge them by their grammar, spelling, syntax, punctuation, clarity of expression, and logical consistency.
Balthazar Lestrane
Dirt 'n' Glitter
Local Is Primary
#10 - 2013-07-05 20:25:17 UTC
+1

Getting blueballed due to poor server management shouldn't be happening.
1Robert McNamara1
Ministry of War
Amarr Empire
#11 - 2013-07-05 21:10:48 UTC
War Kitten wrote:
I'm not sure how your proposed system is different from what we have now. Even if there aren't any aggression timers going, the people in the systems that you shut down will still get disconnected. It's not any more seamless than it is now.



Setting aside the poor parallel with MCUs (not accepting new connections was me adding too much information that confused the analogy).

Currently CCP has a means to move solar systems off a node, however it has lead to a couple spoiled fights (giant, game changing fights) due to human error. My proposal would introduce a method for systems moves to occur only once PVP in that system have concluded. This would allow CCP to execute these commands without fear of human error ending important fights, and for smaller conflicts in the area to also be resolved prior to being moved.
Lugia3
Federal Navy Academy
Gallente Federation
#12 - 2013-07-07 04:44:40 UTC
It is a good idea, but there are multiple ways of performing a "soft migration", all with pros and cons.

My personal favorite way would be to "freeze" a node, and in the following 30-60 seconds the frozen data is transferred and continued on another empty node. By just freezing and transferring the systems experiencing heavy combat, CCP could avoid dropping other players unconnected to the fight, while still keeping the fight going. All timers, modules, and actions resume once CCP hits the switch to unfreeze the heavy system.

This would prevent people in other systems on a node from being dropped, and not halt/destroy the fight either. In the recent "error" where CCP moved the heavy combat system by accident, the majority of both fleets never logged back in to continue with the fight.

"CCP Dolan is full of shit." - CCP Bettik