Announcement

Collapse
No announcement yet.

An actual DR Manager

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • An actual DR Manager

    Working in an architecture firm, we do not approach rendering the same way as a typical production house. Most of our users only have a cursory knowledge of hardware and software and also have a tough time coordinating with each other.

    We do have a render farm, but most of the users either don't know of it or their own misconceptions prevent them from learning how to use it ("it seems so complicated"). Looking at the log, out of 30 or so vray users, only about 4-6 use our farm consistently. We've tried to handle this from the education side but most of our users simply prefer to watch the render develop on their local machine (often laptops...don't ask), no matter how good we make using the farm look.

    90% of the time, we are doing still renders which makes Distributed Rendering extremely appealing in that it scales nearly linearly vs. a traditional render farm with one dedicated node per job. The only problem is right now the managing of the DR is done client side and is not dynamic. Whoever gets there first, gets it all.

    I don't think we would be alone in the desire for a Distributed Rendering solution that is managed server side, with jobs split between available machines. Most importantly, it circumnavigates the user education issue. Our users rendering could be supplemented by our renderfarm with no change in the way they currently behave. They can still monitor it from their machines, except now it is supplemented by the entirety of our farm. A win-win for us.

    I can understand the caveats with this solution; Instead of a first come, first served client managed setup, how would the manager decide what job goes where? Test renders are often canceled early into the job and as more users come online nodes would be diverted, thus making this whole process less than efficient. But needed, nonetheless, in my opinion.

    Any thoughts?

  • #2
    It's come up before; not that I'm opposed to it, but it's a ton of extra work that is not directly related to the renderer. Deadline already does some of that and since the next service pack of V-Ray allows dynamic add/remove of DR servers during rendering, it's supposed to work quite well.

    Best regards,
    Vlado
    I only act like I know everything, Rogers.

    Comment


    • #3
      Thanks for the quick reply, Vlado. I didn't think at looking at other managers. The separation of renderer and manager makes sense. I'll check it out.

      Comment


      • #4
        I have been thinking about this a while now, after testing out diy "cloud" rendering services for DR.
        The biggest issue I see now is inefficiencies in network traffic (or so it seems). Sometimes slaves can use multiple hours on a bad day to join the rendering.
        I think Vray's spawner needs a separate Master-hub that you install that talks to each slaves spawners, so sending a job over the interwebs only sends it to this hub, and this hub then proceeds to distribute it to its slaves.
        This way the submitting machine only talks to the hub(s) and keeps the spamming to a minimum as the slaves only talk to their hub as well. Adding some sort of info feedback on current jobs and owners of said job for team use per hub would let us coordinate better who does what when.
        One should be able to have multiple hubs if needed. This combined with what you outlined above would make dr a lot better.
        Is this at all feasible?
        Signing out,
        Christian

        Comment


        • #5
          Well, ideally you wouldn't be connecting those DR slaves directly to your workstation. The best approach would be to run a single command-line render on the cloud and that one would talk to the other cloud slaves. In that case the communication will be kept only within the cloud and would be supposedly superfast.

          It's kind of similar to what we did with the V-Ray Cloud and live rendering from Motion Builder - having motion builder to directly talk to the cloud DR servers was extremely inefficient, so we added a master machine on the cloud that would handle all the internal communication with the slaves, and Motion Builder would talk only to that master machine.

          Best regards,
          Vlado
          I only act like I know everything, Rogers.

          Comment


          • #6
            Yes. that is exactly what I meant, though I might have muddied it up with my writing.
            This would be great for renting dr nodes on the fly around the world.
            Signing out,
            Christian

            Comment


            • #7
              Oh yes, I can't stress how much something like that would be great.
              Actually, even for internal renderfarm where the hub could be wired with 10Gb to the switch. This would free up the need for the workstations to be connected to 10Gb.

              Stan
              3LP Team

              Comment


              • #8
                The hub technique is a valid strategy for remote networks. This is already available but a bit off-topic of my original ask.

                I looked into Deadline, but it looks like it manages spawners the same way....user selects spawners, they get reserved and participate on users rendering. It does have the benefit of managing traditionally submitted jobs and DR jobs together. That would be a requirement, but still does not fulfill the original scope of the request. I would rather have the manager handle the assignment of spawners. Are there any other options out there?

                I understand this may be beyond the means/desires of Chaos group, but I thought I'd start here, regardless.

                Comment


                • #9
                  Originally posted by pkolbo_pop View Post
                  I looked into Deadline, but it looks like it manages spawners the same way....user selects spawners, they get reserved and participate on users rendering.
                  That's the situation now, because V-Ray doesn't allow adding/removing servers on the fly; this is added for the next service pack. So things will get better.

                  Best regards,
                  Vlado
                  I only act like I know everything, Rogers.

                  Comment


                  • #10
                    Understood. We'll stay tuned. Thanks again, Vlado.

                    Comment

                    Working...
                    X