Hey guys, our company is trying to find a good system to use for our conference calls that allows us to control our desktops and have the clients view our desktops that we are showing. For video play back and quick fixes... Any ideas on what we should try?
Kevin M. Bourke, BourkePR
Phone: (508) 259-6018
FOR IMMEDIATE RELEASE
Mobile Imagination Extends Reach of the doddle Platform into Canada
Seasoned Television and Film Industry Executives, David Plant and Bryan Milne, Drive Efforts to Bring New Efficiencies, Reduced Costs to Canadian Production Industry
with doddle Platform
Boulder, CO (September 12, 2012) – Mobile Imagination LLC (www.doddleme.com) today announced it has extended its growing reach of the doddle Platform into Canada with the launch of doddle Canada. Headed by seasoned television and film industry executives with deep roots in the Canadian production industry - David Plant and Bryan Milne - doddle Canada is bringing the Company’s online, collaborative call sheet and planning solutions platform for production planning and logistics management to the Canadian production industry.
“Toronto and Vancouver are home to the largest television and film production communities in North America, and they are clamoring for new techniques and technologies to help them be more efficient, more cost effective and more importantly, environmentally responsible,” said David Plant, co-founder of doddle Canada. “We are so impressed with Mobile Imagination and what they’ve built with doddle. There is a very real need for the doddle Platform in this ever expanding community of filmmakers and we’re looking forward to bringing it to our colleagues throughout Canada.”
“The launch of doddle Canada is an important milestone for us; as we continue our expansion to production communities all over the globe, the addition of new regions makes the doddle Platform that much more powerful for users,” added Jim Robertson, co-founder of Mobile Imagination. “No one understand the requirements of the Canadian production community like David and Bryan. Under their stewardship, we’re confident that resources like doddle PRO and the Canadian doddle Directory will quickly become indispensable, highly valuable go-to solutions for our customers there.”
For more information about doddle Canada or to contact the management team, please email email@example.com.
What doddle is All About: The doddle Platform
doddle is based on a powerful platform developed by Mobile Imagination to create collaborative, mobile and cloud-based efficiency tools for businesses and creative professionals.
Today, the Company provides four primary offerings for the professional production community:
The doddle Directory for the iPhone: doddle is the first entirely free interactive, digital mobile production resource guide for the film and video industry. doddle is designed for anyone involved in the production process and provides easy access to key resources and information to help find anything and anyone required for a shoot - from producers, directors, photographers, grips, gaffers, sound and talent to information about hotels, restaurants, catering, transportation, even the local weather forecast.
doddlePRO is a mobile, collaborative call sheets and productions planning efficiency tool optimized for the desktop/browser, iPhone and iPad.
doddlePRO Online is a browser based version of the Company’s collaborative call sheets and planning tool, ideal for larger productions and teams coordinating efforts from a central location and communicating to its people in the field. doddlePRO Online automatically synchs with iOs devices and provides a powerful hub of logistical operations for the crew.
doddleNEWS is a free online news service with daily industry news for the production community, reported by creative production professionals. It includes industry news for pros, reported by pros with the primary goal of delivering credible, valuable and relevant content for the community.
To date, production companies have used doddlePRO to manage the logistics of major television productions, such as EXTRA; commercials and promos for Toyota, NASCAR, NBC’s The Voice, TaylorMade golf shoes, and for the New York Knicks; stage productions like Billy Elliot; by entrants in the 48 Hour Film Festival; and at media production companies like Manhattan Place Entertainment. Additionally, doddlePRO is used by 5 Creative/Channel 5 UK to produce Big Brother UK, and is in trials at the BBC Scotland and is being considered for company-wide deployment.
About Mobile Imagination, LLC
Mobile Imagination develops collaborative mobile and cloud based apps and services for business and creative professionals that take the pain out of logistics and data management associated with just about any project. Today, the Company provides a family of solutions for the professional production, television and film community and have designed a family of mobile and cloud-based solutions to help create a paperless, highly collaborative workflow experience for the filmmaking and television production community. The Company’s solutions are tailored for everyone from indie filmmakers to the world largest broadcast operations. The company was founded in 2009 by software industry and professional production industry veterans Jim Robertson and Rich Kwiat. For more information, please visit www.doddleme.com.
What is a Cross-Platform Link-Based Directory Structure?
A link-based directory structure is created completely using links so that both UNIX and WINDOWS systems can easily access files in a similar manner. Using this method, you can easily maintain tools to automatically create directories and files in a consistent nature. You also gain the ablility to move directories and/or entire projects to new physical file systems while being totally invisible to the users.
What is needed to create a Cross-Platform Link-Based Directory Structure?
Nothing is required to be purchased. All you need is a UNIX server running SAMBA with MSDFS configured.
How to set-up a Cross-Platform Link-Based Directory Structure
First we choose a common drive letter to mount under WINDOWS (in our examples we will choose N:). Similarly, for mounting drives under UNIX, we select the same name as automount drive (/n). By choosing the same path, users will be able to navigate on either WINDOWS or UNIX by using the same standard paths. This also allows conversion mapping when files needs to be moved between WINDOWS and UNIX easily.
netbios name = LINKSERVER
workgroup = YOUR_DOMAIN
host msdfs = yes
security = ads (or whatever you use)
encrypt passwords = Yes
password server = YOUR_DOMAIN_CONTROLLER (or password server)
max log size = 5000
log file = /opt/samba/var/log/%m
use sendfile = no
local master = yes
os level = 3
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
log level = 3
log file = /opt/samba/var/log/%m
utmp = yes
utmp directory = /var/log/utmp
wtmp directory = /var/log/utmp
server string = DFS Server
guest ok = yes
comment = Windows N: drive
path = /export/windows_n
msdfs root = yes
writeable = Yes
create mask = 0774
directory mask = 0775
guest ok = yes
So on WINDOWS we would mount the SAMBA server \LINKSERVERwindows_n as N: and on UNIX we would mount linkserver:/ /export/unix_n as /n
Creating a project under the Cross-Platform Link-Based Directory Structure
For this example lets create two projects (PROJECT1 and PROJECT2) with a simple directory structure: Remember that WINDOWS and UNIX both see different links, so we need to create the real directories on the filers the files will actually be located as well as two sets of links (one for WINDOWS and one for UNIX).
On the LINKSERVER you have two directorues /export/windows_n for WINDOWS links and /export/unix_n for UNIX links.
Create default project directories
chmod 555 /export/windows_n/projects (So WINDOWS users can't create files at this level - otherwise won't be seen in UNIX)
chmod 555 /export/unix_n/projects (So UNIX users can't create files at this level - otherwise won't be seen in WINDOWS)
Note: A physical projects directory doesn't need to be created this is just a fake level.
Create project directories
On your storage create real directories (At this point lets pretend we have only 1 storage filer called STORAGE1), this should be mounted under UNIX under /n if you use automounts. For this example we only have 3 top level directories to make the examples easier, in your studio, you can break down the levels as much as you need to. The more breakdown the better if you are forced to move data a later period of the project due to space constraints. One thing to consider is that users will not be able to create files are directories at the top level, so make sure you create ALL the top level directories that you are going to use. The reason for this is simple, since the directories are actually links, WINDOWS users and UNIX users will not be looking at the same top level so one or the other will not be able to see what is created at that level.
Directories where files will actually be located:
WINDOWS Links: (no files ever located here) (pay attention to the double backslashes)
chmod 555 /export/windows_n/PROJECT1 (So WINDOWS users can't create files at this level - otherwise won't be seen in UNIX)
ln -s msdfs:STORAGE1\PROJECT1\Work Work
ln -s msdfs:STORAGE1\PROJECT1\Render Render
ln -s msdfs:STORAGE1\PROJECT1\Comp Comp
chmod 555 /export/windows_n/PROJECT2 (So WINDOWS users can't create files at this level - otherwise won't be seen in UNIX)
ln -s msdfs:STORAGE1\PROJECT2\Work Work
ln -s msdfs:STORAGE1\PROJECT2\Render Render
ln -s msdfs:STORAGE1\PROJECT2\Comp Comp
UNIX Links: (no files ever located here)
chmod 555 /export/unix_n/PROJECT1 (So UNIX users can't create files at this level - otherwise won't be seen in WINDOWS)
ln -s /n/STORAGE1/PROJECT1/Work Work
ln -s /n/STORAGE1/PROJECT1/Render Render
ln -s /n/STORAGE1/PROJECT1/Comp Comp
chmod 555 /export/unix_n/PROJECT2 (So UNIX users can't create files at this level - otherwise won't be seen in WINDOWS)
ln -s /n/STORAGE1/PROJECT2/Work Work
ln -s /n/STORAGE1/PROJECT2/Render Render
ln -s /n/STORAGE1/PROJECT2/Comp Comp
That's all you need to get started. In WINDOWS if you can navigate to N:projects and see two projects, where as in UNIX you can navigate /n/projects and see the same directories.
Moving Your Data
Now that your projects are created in the Cross-Platform Link-Based Directory Structure you are able to move your data whenever you like and be total invisible to the users.
Above we created two projects (PROJECT1 and PROJECT2) on our single storage filer STORAGE1. Well, the projects are getting two big and STORAGE1 is running out of room, we need to move the data.
In this example, let's say we have a second storage filer available (STORAGE2).
You do have some decisions to make, do you want to move an entire project to the new filer or do you want to move data from both projects? Either way you are covered.
Let's say we decided to move just "Render" and "Comp" directories for all projects to the new storage and keep the "Work" directories where they are.
No matther what your choice is, you will have to sync the data to the new storage filer and make sure the directories are set up the same as the original.
Note: Don't touch the links until the sync in complete! Also, you will need to take the directories down for a bit to do a final sync and make sure you don't lose any data!
Updating Windows LInks:
rm -Rf Render
ln -s msdfs:STORAGE2\PROJECT1\Render Render
rm -Rf Comp
ln -s msdfs:STORAGE2\PROJECT1\Comp Comp
rm -Rf Render
ln -s msdfs:STORAGE2\PROJECT2\Render Render
rm -Rf Comp
ln -s msdfs:STORAGE2\PROJECT2\Comp Comp
Updating UNIX Links:
rm -Rf Render
ln -s /n/STORAGE2/PROJECTS1/Render Render
rm -Rf Comp
ln -s /n/STORAGE2/PROJECTS1/Comp Comp
rm -Rf Render
ln -s /n/STORAGE2/PROJECTS2/Render Render
rm -Rf Comp
ln -s /n/STORAGE2/PROJECTS2/Comp Comp
That's all you need to do. WINDOWS and UNIX users will both see the projects the same way even though the data has been physically moved.
All the above can be scripted so that a single command will create a new project, all the physical directories and both sets of links to your default storage locations. Also, you should customize your pipeline tools so that the link-based system is used and stop any tools looking at specific mounts and/or filers.
Why Load Balance Network Services?
Most network installations have their current network services such as DNS, NIS, NTPD, CUPSD, and multiple APACHE servers all running on seperate physical servers. Natural balancing of all of these services is difficult, if not impossible due to the nature of how often these services are accessed and the resources each service require to perform their function. You quickly notice that while some servers may be overloaded at some regular points of each day; most of your infrastructure servers are hardly utilized at all. It is nice to see that the load on any specific server is low (around 0.01), but what that actually means; is that server is not doing anything most of the time. This means that your servers are wasting resources like electricity and cooling as well as valuable space in your server room. You need all of theses services available all the time so your facility can function. But how can can we even out the load across servers to maintain a consistent load and reduce slowdowns during peak periods?
Many people have been using ro investigating a VMWare solution to consolidate these services on a single machine, however; you usually need fsufficient funds tn order to purchase a large server that has more power than you will ever need to compensate for the overhead of all the individual VMWare instances you will need to load. Then, to be safe, you will need a second one of these overpowered machines for protection in the event your main VMWare fsrver fails. This secondary machine needs to be just as powerful to load all the instances you had running on your primary server. So, you end up having a very powerfull and expensive machines sitting 100% idle all the time which again is a total waste of production (most of the time).
In our case, we didn't have the luxury of purchasing new servers for all our aging infrastructure. We did have some old render nodes that (individually) were not powerfull enough to run all the services we require with everyone accessing them all day, (as well as the additional load required to server our renderfarm) but we had a lot of them. We could go back and just upgrade each of our existing servers, but we would still be stuck with an unbalanced infrastructure. Load Balancing Network Services is what we decided to do.
Benefits of Load Balancing
How-To Setup A Load Balanced Network Services
In our studio, we simply created a master server for services like DNS and NIS that only talks to the cluster of servers that will be behind the Load Balancer. This server is only accessed by a couple of people on our Systems team and the slave servers in the Load Balanced cluster. All the other machines and render nodes in our facility access the Load Balance cluster machines to talk to the services. We also created an installation script for all the Load Balanced Servers using XCAT (eXtreme Cluster Administration Tools) the same way we do for all of our render nodes. The Load Balanced servers are set up as slaves for both DNS and NIS so they keep up to date automatically whenever the master is changed. Configuring the Load Balancer itself was quite simple, we didn't have to change any IP's for the servers in the cluster, create additional VLANs, we practically just plugged the Load Balancer hardware into our CORE switch and configure it to point to the machines we wanted in the cluster (this took about 15 minutes). For APACHE services, instead of running all the web code in /srv/www/ on the local machines as we have always done in the past, we created soft links to a network share, this way all code can be updated in one location (our network share also gives us the benefits of snapshots and being backed up), but all servers in the cluster are automatically updated. These features of the installation setup also add to the simplicity of adding or rebuilding servers in the cluster as most of the configuration is static. Just make sure that whenever you do make a change to any of the services, make sure you also update your installation script.
Basically, all the servers are set up from the same script and installed exactly the same way, we use DHCP on all of these machines so they get different names and IP's (hardcodes in DHCP so they always get the same IP). The Load Balancer then checks to see which nodes are available and all services are evenly distributed to one of them. The clients all point to the load balancer for all their requests and it just forward them to the machine it decides they should use. This way all servers are relatively working at the same load as one another all of the time they are being used.
If one of your servers is having a problem, just re-install it from the scripts, or take it off-line. Your services will still be running, just on less machines. As a bonus feature since all servers are the same and installed using a script, there is no need to back up any of the individual servers on the cluster.
If your servers are getting overloaded, just add more machines to the cluster. Your Load Balancer will allow you to control the percentage a certain server so if you have more powerful machines, you can keep the load evenly distributed for future growth.
One last thing to note, this will only work if the services that are capable of load balancing. You database server and your render manager for instance won't work in this situation, these services have enough load on them individually to keep them on their own server as we have always done in the past. Some of your Apache services might have to be changed a little depending on how you control authentication and session management.
Happy Load Balancing.