About 6 months ago I posted here saying I was thinking about cancelling the server hosting US1 because I am not happy with its performance given the very high cost. I have finally put in a cancellation request and will only have the server through early July.
I will replace the server with one hosted on Amazon Web Services and will not be using the server for anything except for Allegiance. One benefit of AWS is there is no charge for RAM or CPU if you switch off the server and RAM+CPU is most of the cost.
So I am here to ask what hours do you need the server running? I doubt you need it running for random 1v1 or 2v2s that might happen at non peak hours since Mach3 should be fine for that. I don't think Allegiance is played much at all on weekdays anymore? Perhaps US1 might be available for between 4 and 6 hours on weekdays and like 12 to 14 hours on weekends? I have no idea when Allegiance is actually played anymore, so I need some help with that. I am happy to run the server whenever needed but no point in throwing away money having the server switched on when no one is using it.
I may not end up setting specific hours though. It should be possible to get how many players are logged into ACSS and if like 5+ are logged in US1 will turn on automatically. Then I'd probably set it to automatically shut off after 30m to 1hr of 3 or less being logged on. In case there are a bunch of AFKs, I'd probably also have a set cut off time very late at night.
US1 Server Replacement
I recall that someone (jammer?) had a graph that showed the activity by hour by weekday. Dunno if that webpage is still up or not.
The auto on/off feature of the server is a great idea. I'd ask if BT could tweak ASGS to incorporate an "available" feature that could pool up enough players that would then trigger the server to activate. If you put a minimum limit at say 4...anyone who is in the "available" pool could see how many are meeting that limit....ie...the player who wants to join the server would see that there are 3 of the necessary 4 needed to launch the server thus; they could predict how long it might be before the 4th player became available.
just some thoughts
The auto on/off feature of the server is a great idea. I'd ask if BT could tweak ASGS to incorporate an "available" feature that could pool up enough players that would then trigger the server to activate. If you put a minimum limit at say 4...anyone who is in the "available" pool could see how many are meeting that limit....ie...the player who wants to join the server would see that there are 3 of the necessary 4 needed to launch the server thus; they could predict how long it might be before the 4th player became available.
just some thoughts
I was wondering if something like that would work:
1. host is as a real linux machine or just a docker machine
2. run qemu/kvm (as is or in a container, see https://github.com/Ulexus/docker-qemu ) to run Windows Nano Server in guest mode with Containers support enabled (see : https://msdn.microsoft.com/en-us/library/mt126167.aspx )
3. run allegiance server instances in Windows containers in the Nano server.
Technically I see nothing unfeasible here...but "the devil is in the details" and there are a lot of layers
The advantage is that for $5/month we can have a 24/7 cheap VPS server that can host this. (see vultr.com or OVH.com (europe/canada only)).
Another advantage is to run more than one allegiance server on a single host (1 container = 1 allegiance server and a Nano can run several containers).
Another advantage is that Windows containers are coming to Windows 10 so one could host an allegiance server without messing his local computer (registry, dll, etc).
ofc all of this is a bit early because Windows containers are still been developed by Microsoft (see this) and will be released with Windows Server 2016.
but might be worthy trying to make this work.
1. host is as a real linux machine or just a docker machine
2. run qemu/kvm (as is or in a container, see https://github.com/Ulexus/docker-qemu ) to run Windows Nano Server in guest mode with Containers support enabled (see : https://msdn.microsoft.com/en-us/library/mt126167.aspx )
3. run allegiance server instances in Windows containers in the Nano server.
Technically I see nothing unfeasible here...but "the devil is in the details" and there are a lot of layers
The advantage is that for $5/month we can have a 24/7 cheap VPS server that can host this. (see vultr.com or OVH.com (europe/canada only)).
Another advantage is to run more than one allegiance server on a single host (1 container = 1 allegiance server and a Nano can run several containers).
Another advantage is that Windows containers are coming to Windows 10 so one could host an allegiance server without messing his local computer (registry, dll, etc).
ofc all of this is a bit early because Windows containers are still been developed by Microsoft (see this) and will be released with Windows Server 2016.
but might be worthy trying to make this work.
Last edited by KGJV on Tue Jun 14, 2016 3:11 pm, edited 1 time in total.
I don't really see much advantage in running a container on Nano except to run multiple servers (we have no use for more than 1) or isolate it from everything else on the server (in my case I have no other use for a Windows server, so if I am running it that wouldn't help me). If Alleg server could run directly on Nano that would be beneficial in running on smaller virtual servers, but that won't be possible. If it was run in a container, wouldn't the OS of the container still require the same resources? It doesn't seem like that would help save money by going with lower specs. Maybe I don't fully understand the Nano server though.KGJV wrote:QUOTE (KGJV @ Jun 14 2016, 09:10 AM) I was wondering...
Also Vultr and OVH both have bad networks and less than ideal stability, so those are not suitable options for a game server (at least not a single location used by people all over the world like Allegiance).
The alternative I was considering previously, besides turning the server off when not sued, was to strip down Windows Server 2012 as much as possible with the main thing being turning off the GUI after installing Allegiance server. I am not sure how significantly it would reduce resources though although I was thinking reducing to 1GB of ram should easily be doable. I intended to test this, but never got around to it. I probably still will eventually. For an ultra cheap server this could be combined with running the server limited hours.
Last edited by aem on Tue Jun 14, 2016 8:57 pm, edited 1 time in total.
advantage of nano: headless server requiring less resources.
Going for a headless full Windows Server would work too I guess.
The big point of containers is the easiness to setup and update things. No need to install manually alleg server and whatnot, just run the container (granted someone has already build a container image containing everything needed to run alleg server).
something like
(all you need is Docker, everything will be downloaded and run automatically after typing this command).
The image (freellegiance/allsrv:windowsservercore) must be published on a public repo (Docker or Microsoft) and maintained/updated by the dev team when new code is available.
That would simplify things tremendously (but yeah given the state of the game not sure that would help much but that's another story...)
That's the whole point of containers and Docker: from devs to running the code directly without requiring someone in the middle to 'package, configure install' stuff, plus a almost perfect clone of the environment (same dlls, registry, etc) which reduce issues and incompatibilities & side effects.
but anyway, after some inquiries, it appears Nano server is missing 2 things:
- it's 64-bit only with no 32-bit support (no WoW64)
- no direct support of direct play
so that's pretty it for Nano & Allegiance. For now, at least, unless porting allsvr to 64-bit is easy... which I doubt.
But using containers on a regular windows server should be possible.
Going for a headless full Windows Server would work too I guess.
The big point of containers is the easiness to setup and update things. No need to install manually alleg server and whatnot, just run the container (granted someone has already build a container image containing everything needed to run alleg server).
something like
Code: Select all
docker run -d -p.... freeallegiance/allsrv:windowsservercore ip_of_lobbyThe image (freellegiance/allsrv:windowsservercore) must be published on a public repo (Docker or Microsoft) and maintained/updated by the dev team when new code is available.
That would simplify things tremendously (but yeah given the state of the game not sure that would help much but that's another story...)
That's the whole point of containers and Docker: from devs to running the code directly without requiring someone in the middle to 'package, configure install' stuff, plus a almost perfect clone of the environment (same dlls, registry, etc) which reduce issues and incompatibilities & side effects.
but anyway, after some inquiries, it appears Nano server is missing 2 things:
- it's 64-bit only with no 32-bit support (no WoW64)
- no direct support of direct play
so that's pretty it for Nano & Allegiance. For now, at least, unless porting allsvr to 64-bit is easy... which I doubt.
But using containers on a regular windows server should be possible.
Last edited by KGJV on Tue Jun 14, 2016 11:15 pm, edited 1 time in total.
First off, thanks for all the time and money you put into this.
I would say it would be great to have it just plainly On Fridays- Sundays. It is the preferred servers, and most weekends some at least 4 vs 4 break out all 3 days.
as far as this:
I would say it would be great to have it just plainly On Fridays- Sundays. It is the preferred servers, and most weekends some at least 4 vs 4 break out all 3 days.
as far as this:
If a comm goes afk, it would really suck to have no way to go to a second server if no @alleg is available. maybe implementing an auto kick afk comm > 5 minutes would be a fix?AEM wrote:QUOTE (AEM @ Jun 14 2016, 04:56 PM) I don't really see much advantage in running a container on Nano except to run multiple servers (we have no use for more than 1)
*#$@faced $#@!tard Troll
Np, paps contributes a lot towards the server expenses so thanks to him. Generally around $30 per month to run a capable virtual server with Windows Server license 24/7 which isn't that much. Disabling the GUI may be able to cut that in half, but haven't tried it to see if it is stable enough with low memory.
We have one actual server now, but multiple games can be created on each server.Ryujin wrote:QUOTE (Ryujin @ Jun 14 2016, 08:07 PM) If a comm goes afk, it would really suck to have no way to go to a second server if no @alleg is available. maybe implementing an auto kick afk comm > 5 minutes would be a fix?
Last edited by aem on Wed Jun 15, 2016 2:43 am, edited 1 time in total.
Not sure if helpful, but I wrote an AWS Lambda function (in python) for work that auto starts/stops EC2 instances based on "Start time" and "Stop time" tags on the instance. Sounds like you're going to set up something a little more sophisticated, though, based on player count.
"Leave Bacon alone. When he's unsure of what sector he's in somehow it works out better." -Lee
The new server is running named USA. Memory usage is lower than expected installed on 1GB memory instance with only 64% memory being used. So I think I will give this a try as is. If there any issues I will disable the Windows GUI and see if that makes it stable. If that still does not help, I will move up to a server with higher specs. For now it will run 24/7.
If we have any larger events I can always temporarily scale the server up too.
If we have any larger events I can always temporarily scale the server up too.