Hi
We’re setting up more slaves in another subnet 10.10.. so we modified “dbConnect.xml” to include the new subnet
org:
<Hostname>render01.local;10.0.0.101</Hostname>
mod:
<Hostname>render01.local;10.0.0.101;10.10.8.105</Hostname>
The slaves in the new subnet all connects to the repo and db with 10.10.8.105.
If we try to submit jobs from C4D R16.038 with the new settings from the old subnet 10.0.., Cinema crashes.
Are we doing something wrong when we’re adding the new subnet to “dbConnect.xml” or this a bug?
DL 7.1.0.35
Cheers
Bonsak
Wow. I’ve never seen an issue in DeadlineCommand take down an application.
The worst thing that should be happening is that DeadlineCommand is failing longer. Could you run something like
"C:\Program Files\Thinkbox\Deadline7\bin\deadlinecommand -pools
and see what happens?
If I were in the same situation, I’d probably configure the routing deal with getting requests from the 10.10.8.X subnet to the 10.0.0.X subnet. It will speed up DeadlineCommand considerably.
Hi
Running:
/Applications/Thinkbox/Deadline7/Resources/deadlinecommand -pools
takes 10 seconds to complete without the other subnet specified, and 1.5 minutes when its set up to include the other subnet. It lists all the existing pools very quickly but then hangs for the rest of the time.
I’m not sure i understod what you meant by:
Cheers
Bonsak
1.5 minutes is about what I expect. The problem internally is that the C# driver for Mongo tries to open a connection to every address specified in the dbConnect.xml file. When it does that, for any address which is not connectable, it has to wait for a TCP timeout within each connection thread the Mono framework to be allowed to quit. I’m told this is really only an issue during startup of a Deadline application, but because DeadlineCommand starts up fresh each time, it will be the most noticeable.
Now, for the routing suggestion.
In a normal network, there is routing hardware which inspect packets and determines what machine a network request should be delivered to. For example, here we have about 8 subnets (on VLANs), and requests are routed by our core switch to the correct destination subnet. Here’s the basic diagram in text goodness: (not exactly what we have, but sufficinet)
[Core-01: 10.0.1.1, 10.0.2.1]
[Leaf-01: 10.0.1.x]
[Leaf-02: 10.0.2.x]
One of our leaf switches handles upstairs, while the other handles downstairs. The core switch connects to both of them, and has its own IP address on each as well. When someone upstairs on 10.0.1.x requests a resource downstairs on 10.0.2.x, the request initially hits Core-01 because the request is not destined for 10.0.1.x and Core-01 is the ‘default route’ for all machines. If Core-01 detects that the packet is supposed to go to 10.0.2.x, it forwards it to Leaf-02 downstairs so that switch can deliver it.
In your setup, any machine in the network should be able to connect to 10.10.8.105 regardless of its subnet. That is unless the network is completely segregated for security reasons. Setting up the routing infrastructure should be all that’s needed to keep using the 10.0.0.101 address everywhere.
If that’s not possible, you could also change the hosts file on the second set of machines which specified that “render01.local” point to “10.10.8.105”, but that is not a reasonable solution.
Thanks a lot! I’ll look into it.
At the moment we only have our repo and fileserver connected to the other subnet over VPN due to limitations in our current network setup ( Airport Extreme 
)
We might need to get a new router that can handle OpenVPN setups so that we can setup something similar to what you’re describing. ( The other subnet is offsite )
We have 40 slaves on the 10.0.0.* subnet and plan to extend with 10+ slaves on the other subnet. Might scale to 40-50 in heavy production periods.
Any tips for a solid router make/model is most welcome.
Cheers
Bonsak