Azure Setup
Options
Hi all, I've just joined this forum today.
I noticed that in the latest Photon roadmap mailout it mentions that Photon runs on MS Azure. I have an Azure account and was wondering how did the Exit Games team go about setting up Photon? I.e. using xcopy to install the server binaries onto a Hosted Service image or build a custom Windows Server VM?
My experience so far with Azure is that it's more like a Google App Engine than EC2, where you build web app using their platform SDK and storage, instead of having a free for all sandbox OS where you can install your own servers and dbs.
I had a search around the forum and google, but all I can find is this post which doesn't really contain much instructions:
http://forum.exitgames.com/viewtopic.php?f=6&t=8&start=10&hilit=azure
Any help would be much appreciated.
I noticed that in the latest Photon roadmap mailout it mentions that Photon runs on MS Azure. I have an Azure account and was wondering how did the Exit Games team go about setting up Photon? I.e. using xcopy to install the server binaries onto a Hosted Service image or build a custom Windows Server VM?
My experience so far with Azure is that it's more like a Google App Engine than EC2, where you build web app using their platform SDK and storage, instead of having a free for all sandbox OS where you can install your own servers and dbs.
I had a search around the forum and google, but all I can find is this post which doesn't really contain much instructions:
http://forum.exitgames.com/viewtopic.php?f=6&t=8&start=10&hilit=azure
Any help would be much appreciated.
0
Comments
-
yunspace wrote:I have an Azure account and was wondering how did the Exit Games team go about setting up Photon? I.e. using xcopy to install the server binaries onto a Hosted Service image or build a custom Windows Server VM?
On Azure you have basically three options 1) Web Role 2) Work Role and 3) VM Role. #1 and #2 are plain Server 2008R2 fully patched. (#3 is your own image.)
#1 and #2 how the BIG advantage that you do not have to take care of the OS and patching, BUT you have to install all apps you need when the instance boots up.yunspace wrote:My experience so far with Azure is that it's more like a Google App Engine than EC2, where you build web app using their platform SDK and storage, instead of having a free for all sandbox OS where you can install your own servers and dbs.
Not really. As I explained above #1 and #2 are perfectly patched OSes and you can connect via remote desktop. You get events at startup and can install do pretty much everything you need.
One thing is tricky, once you ramp up more instances of your app all traffic is going through a load balancer. You can't control to which instance the connection is going - which is essential in our case. We implemented a solution for that - now you can control on which instance you connect.yunspace wrote:Any help would be much appreciated.
We will release an Azure "powerup" that lets you run Photon on Azure soon.0 -
Hi,
we are running Photon in Azure in a WorkerRole.
In the WorkerRole class (derived from RoleEntryPoint) we use the OnStart method to copy Photon from the Azure deployment package to the 'Azure machine'. After that we start Photon using the _run-Photon-as-application.start.cmd script provided with the SDK.
This is just a quick headstart, we will provide examples to this in the near future.0 -
Thanks for all the prompt response. I managed to set up the certificates and gain remote access to my Web role instances. I can now see how having multiple instances can causes issues.
Markus has answered my next question. I will have a go playing with the worker role tonight.
Just a thought on something unrelated, by directing clients to specific instances, that's effectively making each instance a separate shard or a game right? Would it be possible instead to have clients connect to multiple instances which share the same data store reflecting the same game? Perhaps a in memory cache of some sort to minimise db calls.0 -
Hi there,
I've got an additional questions regarding Azure. What about the cases where I'm running multiple role instances and the amount of role changes? For instance, due to a critical error or an application scaling event? I've been taught that Azure apps should be stateless due to such events...
- How does Photon work in that regard?
- Do you have any recommended practices?
- What about having multiple role instances (min 2 - due to MS granting SLA at 2 role instances minimum), and the azure load balancer which acts in a round-robin way? How does Photon go about that?
I'm eagerly looking forward to your reply
Best regards 0 -
mmisztal wrote:Hi there,
I've got an additional questions regarding Azure. What about the cases where I'm running multiple role instances and the amount of role changes? For instance, due to a critical error or an application scaling event? I've been taught that Azure apps should be stateless due to such events...
- How does Photon work in that regard?
to clarify, what exactly is meant by "stateless", photon is
- stateless in the sense that it doesn't persist anything
but is
- statefull in the sence that it holds state in memory (rooms, message queues)
Removing the in-memory-statefullnes for applications like games is very expensive
because of higher costs in resources (hardware) and increased complexity in the overall
system. This has manly to do with the fact that games are fast paced (ev per second)
and because you typically need to lock objects and distributed locks are expensive and will
cause increased rtt.
Considering that hardware failures do happen a lot less frequently than for instance planned downtimes. In azure you have
- reduction of instances as one case of a planned downtime: You have under your control when to reduce instances and azure shuts down the instance with higher instance number. So you can let those nodes quite down, before you reduce the number of instances.
- the others are HostOS updates: you have up to 5min to deal with this - we recommend to send clients an event and you deal with the situation.
- and GuestOS updates: you can opt-out, so this won't happen ...
- and obviously your own service updates: you can opt to do it like host os updates if it is a important fix or inform you users of a planned update.
As for hardware failures - the most important in our view is that your service recovers quickly from the failure.
Obviously the games that where running on the node that failed are gone - but usually players can live with that ...
Our Loadbalancer architecture (see photon sdk) does support most of this out of the box. If a game server fails - games reconnect to the master - where players can choose to join a new game and are forwarded to a healthy node.
What you still would have to take care of is with the failure of the Master - the application it self is ready for "selfhealing" - for instance bringing up a new node when the old fails - the master will sync with the information of all gameservers quite quickly so it can service the requests of players. We are working on a solution for azure - but we don't have a planned release day jet.
The idea is to use the new azure features Custom Probes and Port Forwarding - and have a hot failover master instance.mmisztal wrote:- Do you have any recommended practices?
I'd recommend having a look at http://doc.exitgames.com/photon-server/LoadBalancing and http://doc.exitgames.com/photon-server/pask.mmisztal wrote:- What about having multiple role instances (min 2 - due to MS granting SLA at 2 role instances minimum), and the azure load balancer which acts in a round-robin way? How does Photon go about that?
Since June 2012 Azure supports UDP and the concept of PortForwarding - allowing to by pass the loadbalancer.
See our PASk documentation: http://doc.exitgames.com/photon-server/paskmmisztal wrote:
I'm eagerly looking forward to your reply
Best regards0
