Is it possible to use the Azure Gateway type without Azure Cloud Services / AzureSilo ? #1811
Comments
|
This is of course a 100% supported setup. The deployment is totally orthogonal to system store. You don't need to do most of what azure host is doing in its setup. Just configure the silos and the client to use azure table system store, and use the same deployment I'd. |
|
That's good news; here's what we have on the Silo Configuration: And here is the client configuration: I can see a Globals.UseAzureSystemStore but that has no setter and looking in the code is checking to see if a bunch of these things are set. What am I missing ? If I try this configuration I get an error on the client |
|
Seems correct, but probably something is missing. Not sure what @jdom is now an expert on configuration. He has been adding a lot of support for programmable configuration recently. Maybe he can spot the problem. |
|
If I remove the line:
@jdom Can you see anything wrong with this ? I'll ask on Gitter if anyone has a set of work configuration settings they could share with us to see if that helps. |
|
As Gabi mentioned, this scenario is supported. What is in these values? You also mentioned that if you remove I did try to run a unit test and rely on Azure tables for connecting clients with silos, and it did work fine, without using AzureSilo |
|
Thanks for the response @jdom. Those settings I what I picked up from the code in the work from @ReubenBond on ServiceFabric, I can remove them and try again if they are not needed. I did forget to say that we have the Client.XML with the port assignment in it at the moment because of this issue but whenever I test I remove the code which loads it in Orleankka. I've only tested Azure Gateway with the Emulator and I've read a couple of issues which suggested this might not work, is it worth me trying without the emulator ? I'll report back shortly. |
|
In the quick test I did locally, I'm actually using the emulator. BTW, I'm still interested in knowing which values you used for these settings: |
|
I mean, I'm not familiar with @ReubenBond 's implementation, but do you know what those values hold? |
|
Hey @jdom, I try to answer your question first: The values for ActorSystemEndPoint.Port = 11001, HostOrIPAddress = 192.168.137.92, ProxyEndPoint = 11002. So I removed the lines from the Config.Defaults and I also made sure that the Client.xml was no where to be seen in the deployed code and also remove the line that loaded them. I reset the AzureTableStorage Emulator so it was blank and then I started the Server; this is the output I got: The silo does appear to start and settles down as normal. Here is the log from the client as it tries to connect to the silo. You can see that it could not find any gateway, I've checked and re-checked the DeploymentId and they are the same on both the Silo and the Client. It is possible to share the little test project you put together ? I can check to make sure it runs in this environment. Then it would only leave something in the Orleankka configuration which prevents it connecting. |
|
One odd thing that I see in your silo log is: |
|
BTW, if what you pasted in the beginning of the thread is your entire cluster config, then probably the |
|
BTW, the test is in PR #1818. Basically that PR makes sure the static gateway list is not present in the client configuration and that is really using the membership from azure tables. Any test in the |
|
Thanks for the insight @jdom, so I definitely need to set the config.Default.ProxyGateway then ? I'll check it. From my perspective I don't have a clear idea of what should be set on the Silo and Client for this situation. I've always found the whole startup process a bit of a black art dependency on the environmental situation. |
|
Did it work for you when setting |
|
I've made some progress as I can connect a client and service on my local machine using Azure So I can changed the IPEndpoint for the Gateway from See why this works now as when the Azure records are retrieved by the client it needs the The problem is it does work if I push to the servers in the cloud. All the firewalls rules are good and I start both silo and they pick up there address etc. The client then starts on either silo and start trying to talk to 127.0.0.1 which is the loopback on the slio yes but then continually errors with I see in both the logs of the machines in the cloud that they can see each other also: I'm not sure how it works out the silo is at 127.0.0.1 because I see the registration on the server as 👍 Why is the client not using 10.0.2.4:11002 and using 127.0.0.1:11002 ? Out of interest also why is the IsPrimaryNode showing False ? Should I be setting an IPAddress somewhere on the client even though it's running on the same machine as the Silo ? |
|
Hmm, don't really know why it's getting 127.0.0.1, since the list should now be retrieved from azure tables, and the silos should be correctly writing their real IPs. IsPrimaryNode is expected to be false, that's only used in a dev environment without using external membership service (such as azure tables), so one of the silos acts as the primary to provide the cluster membership. |
|
Also, be aware that if you run the client and the silo in the same VM there could be some side effects when you run it under heavy load. Not sure about security implications either of putting the silo in the same node that serves external requests. Just a heads up |
|
Ok, it was probably trying to use this storage when I had the original bug so that might account for the entries with 127.0.0.1. I'll try stopping the services, clearing down the storage and firing it up again and see what happens. I'll agree on the security implications and the plan was to move the API service out in the network to a different subnet with an NSG on different servers but we were trying to keep the costs down during development. @jdom, @gabikliot - Thanks for sticking with me on this :-) |
|
I've cleared down the Azure Tables and restarted the Silos, everything looked ok and I think I see evidence in the logs they are talking to each other. Tables have re-appeared in the storage as expected. The clients are still trying to use 127.0.0.1 to connect. I'm just going through my code, orleankka code and Orleans code to see if I can figure out what is expected from a code configuration point of view. Here is a snippet from the client log; I don't see how it can be configured for Gateway Provider Config AND have the Azure details. I'll keep looking: |
|
We think we had a deployment problem in the last round of changes which has now been sorted and the client now connects in deployed environment as well as development. All working now. I was wondering if it would be beneficial to create a demo project with TopShelf and Code Configuration to show how we got it to work and share it. |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
We've recently move away from Cloud Services to TopShelf implemented exe's to allow us to deploy more rapidly.
If we configure to use Gateway Ports etc. everything connects up but I couldn't figure out why I couldn't just continue to use the Azure Gateway type without using AzureSilo ?
I've had a dig through the source and I can see the AzureSilo is doing a bunch of additional work. So I thought I'd stop and ask if this is a supported configuration.
If it is support then the outlining code configuration settings for the silo and the client would be much appreciated.
NB. I've checked out the ServiceFabric Azure @ReubenBond built as that works but we are using Orleankka so I don't think I have access to the host to perform some of these operations. I've asked this question around the other way over at the Orleankka repo site.
The text was updated successfully, but these errors were encountered: