Terry,
Encoding does take some time. Depending on the method and settings it may be a 1:1 ration. So if it is a 2 hour data file, it would take about 2hours for at least one of the 6 formats to encode. The fastest may be on the order of 30-45 minutes. So to do the 6 streams, would take about 9 hours? If one machine is doing this, that would take 9 hours by 3000 or about 27000 hours. being that there is about 8760 hours per year that would take over 3 years. This is not feasible.
Having multiple X servers would cut the time by X; ie if the project to get caught up would take 3 years, then 3 servers would make that 1 year
Generating on the fly, is not feasible. Now, your having to generate, or regenerate a 2 hours data file per request rather than having the image for transfer. The transfer may take an hour to burn a disk, a disk that has more than one of these files. In other words 3 or 4, or more 2hours encodings to make a 1 hour disk.(maybe up to 8hours play time) I believe over 1000 are done per week. I may be wrong on this. Many files will be onlline, not nearly ALL of them
FORMATS
Well it appears that there is a need for the formats or they would not be asking for it.
Redundancy of Server
With one server it may be simpler, but the point of failure for the entire production, is ONE machine. The ONE machine is limited to the amount that it can produce.
Lets put this in another way. We have a mountain to level. We have a pickup truck and a backhoe. That back hoe can fill that truck with one scoop. Now that truck is overloaded and has to limit
its speed to under 40 mph or risk blowing tires or brake failure. It takes hours for it to go to a location and to unload the load. Mean while everything is waiting for that truck to come back for another load. If you had 10 truck that were timed so that they could all be in motion at the same time, then the backhoe crew is not wasting time. If one truck fails then it is not critical. The rest may continue while that would is repaired. Now if you lose the backhoe, well...
My idea is to keep one production per rendering server. Each rendering server produces each of the versions for that production. Each version will take different times to complete. So to try to have say 6 servers all doing a version may be nice from a software install and function but it takes the sync of the machines all out of time. What I mean is if the machine completion times are;
Machine/Completion time
A)2hr
B)1:50
C)1:40
D)1:25
E)1:10
F) :45
You can see by the time you have done even 10 productions that the time sync is out more than say 11 hours from the slowest to fastest. So in less than one day of running, your 11 or more hours out of sync. For a project that is taking 3 years or more..this gap is huge..
It would be much easier to mirror the servers. I don't mean a raid system. I mean several systems, 6 for example. All the same hardware, software images and all taking one production in a batch stream for all version. When completed it burns a master BlueRay and updates some master network file server. The BlueRay may be shipped offsite for storage. All version of that production is on that one disk. The nfs would allow in house clients to pull and burn whatever is required.
A concern I have is throughput of the disk io. Most systems are designed for burst rates, either a search read, or a file update or even a copy. We are not speaking of that in a production mode. Almost 100% of the time is in writing to the disk. From day one, disk IO is slower than the computing power. I am concerned that the bottle neck is disk IO. To build a super computer I fear would make this issue even worse. This is especially true if the machine is running concurrent vm that are all writing. The more files open the more the heads have to travel to update each file, and the more fragmented on the fly the files are and the slower the writes.
With my idea of each rendering server, the io is sequential and has 100% resources in each batch step of the various versions. When completed it would do the batch copy to the NFS. This would try to keep the fragmentation as low as possible. It would keep head access to a minimum and help to increase reliability by not beating the drives to death...
MAINTAINCE
Since these rendering servers are not on the net, and do one thing, over and over..Software should not need to be "updated". Part of this virtual machine is to have the "same machine" on each real machine. So the issues are, how to move data, not update the machine. IF the hardware can run multiple vm's, great! But it is my thought that one server will be running one vm at best.
SOFTWARE
I'm not sure if the software that is currently used will even do the batch stream at this point. So I'm not sure about the hands free production efforts. YET...
I will check into the SAN servers..thanks
THANKS as always for all the thoughts and comments!!!!!