Fortunately Control Group’s approach to formidable projects allowed us to complete the project smoothly and on schedule. As noted in the aforementioned article, the trick is to break everything down into manageable tasks, and identify which of those tasks are best addressed with technology, rather than manpower. The workstation setup for the two shows illustrates the benefits of this approach nicely.

The Colbert Report and The Daily Show needed nine new workstations set up for the artists, including installing several 2D design suites, 3D design applications, and a host of supporting plugins. Several render farm servers had to match these workstations setups so that the creation of HD elements could be distributed. Since this is a fair amount of equipment to arrange, we wanted to first be sure that the artists would be comfortable in their new environment. We created a “perfect” workstation for each show, and invited the end users to try them out at our office.

After making a few adjustments based on user feedback, we duplicated these master machines to their brethren using OS X’s excellent Apple System Restore utility. Used in concert with a networking technique known as multicast, we were able to get all of the workstations set up simultaneously, saving countless hours of manpower.

The time savings allowed us to get a jump on the real time sink of setting up design workstations – installing plugins. Due to the way many plugins are licensed, the installations had to be performed individually as each user. A team of Control Group employees attacked the 225 some-odd separate installs, completing them over the course of a day or two. Afterwards, specially crafted project files allowed us to test all the workstations and render nodes in a single shot, ensuring that the artists wouldn’t be confronted by a licensing dialog at show time.

As demonstrated at The Colbert Report and The Daily Show, a carefully planned approach allowed Control Group to assist NEP in completing their HD rollout on time and within the budget allotted. The satisfaction of watching both shows in full frame 1080p HD has been well worth the effort. (Getting to hear Stephen Colbert riff on an auto-tuner backstage wasn’t half bad either.)

Here’s a clip of Stephen Colbert enjoying the new HD setup.

Share this:

Tux the Linux Penguin

I work with Linux quite a bit at CG and it comes up in some interesting places. Consistently we find that the largest and smallest systems we work with are running Linux. If it’s a large system, like a database or storage network, Linux can provide the stability, robustness, and uptime required to make the project a success. If it’s a very small system, like an embedded display or a custom purpose device, we choose Linux because of its flexibility.

Over the last year or so, we’ve had a need to spin up many more virtual computers than we used to. It’s necessary to create a handful of  computers for each project we work on and the number of projects that we are taking on at a time is growing. Tools like EC2 and VMWare have made it very easy for us to create new virtual computers, but what about managing them? For Linux there are some great solutions. In this blog post I would like to talk about how we’re using some of the tools to deal with the large number of machines we are managing in Amazon EC2 for ourselves and our clients.

Cloud Control

The first part of the system is Amazon’s Elastic Compute Cloud (or EC2 for short). I’ve written about EC2 before, but to be really brief about it: EC2 allows you to create computers on the Internet quickly and lets you pay by the hour for their use. The instances you create are virtual machines that run in a large Xen based infrastructure that Amazon provides. To customize the software and configuration of the instances, Amazon lets you create snapshots of your computers (called Amazon Machine Images or AMIs) that you can launch new instances from.

It’s hard to say that making an AMI is difficult, it’s just a few keystrokes and a coffee break while the image is prepared and stored for your future use. When you begin to manage dozens and dozens of different images this becomes a problem. It became clear to us that we needed to have one AMI to manage, and build every computer from image dynamically. To do this we needed a way to pass specific information to each instance when it started up and then have a tool customize the instance based on the specific information about it. Amazon provides a method to pass specific information to an instance (it’s called user-data) and the good folks at Alestic have made some great AMIs around it with some good documentation.

Enter the Puppet Master

We have been using a tool called Puppet for nearly two years now to manage a handful of computers. We selected that to manage the whole lot of Linux computers that we were dealing with. Puppet allows us to describe how a computer should work in a general way. We can make collections of configurations for standard things so it’s easy to reuse what we create over and over again. Our Puppet configuration is stored in a Git repository so many administrators and developers can collaborate on it and our server configurations are backed up and version controlled automatically.

Bringing it all together

Puppet decides what configuration to use for a computer based on its hostname. We use the EC2 user data to pass a new instance the address of a Puppet server and the hostname that the machine should assume. When it boots up it sets its hostname and checks in to receive the configuration that we’ve stored for it. All changes to the machine happen through Puppet so we don’t have to spend a lot of time SSHing in and customizing the machine. It’s also very easy for us to duplicate a machine for testing or whatever we need.

While we originally did this to make our lives easier as we manage more machines there turned out to be some really cool side effects:

• Excellent Security: We don’t want to store sensitive information in Puppet. This means no passwords or secret stuff. To resolve this we require all developers and administrators to use key-based authentication to get access to the computers via SSH. This is very handy and it eliminates the need to remember passwords or for an administrator to have to reset passwords for users. Someday I would love to take the next step and have all of our users and machines be part of the Monkeysphere.
• Accountability: All of our configuration is tracked in a Git repository so we can see the history about what has changed on certain hosts and who changed it. Change control occurs automatically with Puppet and it’s easy to examine and understand what has changed and why it changed.
• Repeatability: By storing all Linux computer configuration in a single place we can easily repeat what we did for one server on another. Puppet institutionalizes all of our Linux knowledge in one place and saves us time every time we have to create a new machine. If you want to see how someone has done something in the past there’s no more need to dig through emails or documentation, just look at the facts in the Puppet repository and even copy and paste it into your new configuration.
• Portability: We use Puppet to manage much more than just EC2 instances. Physical machines and virtual machines in our ESX installation are managed this way too. It gives us one tool to take care of any Linux machine we deal with. Puppet also supports other operating systems. We’re looking to expand our use of it to Mac OS X machines and maybe even Windows sometime soon.

There are certainly other ways to solve the problems we’re up against, but this is the way we chose. We did some extensive evaluation of Chef (which is a tool like Puppet) and we’ve used Rightscale before. This sort of thing is becoming very important as we manage more and more computers. I expect we’ll see a lot of exciting products, techniques, and services in this space as time goes on.

If you have any questions or comments about our setup, or would like to discuss implementing something like this for your business, leave a comment or get in touch with us. We’d love to help.

Share this:

Everyone, everywhere, was talking about 3D: cameras, displays, production software, trucks, expertise, etc. The race for preparedness is on, and people will spend as pushy studios and producers want to be the first to do this or that with 3D. First sitcom, first sporting event, first documentary, first newscast, etc. The reality is that we are a ways off from wide-scale adoption, and showrooms and special screenings will be the place for 3D for the foreseeable future. We are in a similar catch-22 phase as a few years ago during the early days of HD production – 3D TVs are just coming onto the market and will drop down to reasonable consumer level prices within the next 2-3 yrs. Consumers are asking “do I buy a 3D TV when there is little to no programming?” while content creators are wondering “do I produce in 3D when there is little to no audience?”

Being an industry event though, it’s about more than bragging rights or audience – it’s about technical feasibility, practice, and logistics – all things which will change when 3D comes to our living room. DirecTV has announced that they will carry four 3D channels starting in June, including ESPN 3D and a dedicated 3D pay-per-view channel. And Cablevision dipped its toes into the 3D pool a few weeks ago with an MSG Network broadcast of a Rangers and Islanders hockey game live from Madison Square Garden.

After talking to a few industry experts who participated in the recent Masters in 3D, the challenges with 3D production are less technical than logistical: camera placement for example. While HD favors wide top-down shots for seeing all the action, 3D is most effective with close, ground-level cameras – imagine Phil Mickelson’s birdie putt as viewed from grass-level, just across the green, the ball rolling right toward you as he sinks it…

There were also lots of other things of interest: Falconstor’s HyperFS, CatDV asset management, Avid’s Java app for editing over the web, 3ality cameras, Adobe CS5, among many more. We were particularly excited by the potential of Active Storage’s Innerpool appliance for metadata. This PCI Express card contains on-board redundant solid-state drives, specifically engineered for storing metadata in an Xsan environment. This has the potential of being something of a game changer, allowing us to more efficiently configure the storage in our Xsan integrations, and giving our clients more bang for their buck when deploying new SAN solutions.

We had some great meetings with prospective clients, old and new friends, fellow consultants and vendors, and we’re excited about some emerging strategic opportunities. Our work in online video technology and web delivery combined with our broadcast infrastructure and workflow experience means we are ideally positioned to help organizations streamline and bring these workstreams closer together.

Share this:

In a recent Cloudsourcing event we held at our offices in the Woolworth Building we had the opportunity to meet many people interested in migrating to the cloud. The most common questions that evening seemed to revolve around “is the cloud secure?” and “will this work for my industry?” Being Google Apps partners and now AWS partners we are able to address client concerns with confidence and provide solutions.

Finding cloud-based solutions and implementing those solutions on the enterprise level can be a challenging task as these are still relatively new technologies. Keeping this in mind, part of the process includes stepping down from the cloud and relying on our team of Project Managers, Account Managers and Engineers along with AWS Consultants. With a solid team we are able to guarantee that a client’s needs and expectations are met in a timely manner.

When you think about the potential for cloud computing, you start to realize the role AWS plays in this game. Cloud computing is just now starting to meet the needs of large corporations and the data center of the future may very well be cloud based. We look forward to forging ahead in this area with Amazon Web Services.

Share this:

This tool is called iozone. iozone is open source and runs on a ton of operating systems (including Windows). It runs several tests which can take some time to complete but provide the best overall view of the capabilities of a piece of storage. For instance, iozone runs a write test with files of different sizes and with different size records (the amount of data written at a time). It does this over and over again with writes, reads, random writes, random reads, and so forth. Since it’s running all these tests you can see what sorts of operations will have good performance and which ones will not perform so well. Check out the iozone documentation here.

One really great thing about iozone is that the output it generates can be easily placed in a spreadsheet program like Excel to generate a great 3d diagram describing your storage. Here’s a diagram I generated from some tests on a Linux server.

Results of a write test with iozone

This particular server performed quite well with large files and a record size around 1 MB (interesting to note, this is the same storage from the lmdd post. Notice that the parameters I tested with there are the same as the best write that this disk can do according to iozone!).

If you’ve been following my posts on storage performance testing I hope you’ve learned about some new tools that you can use to see what’s going on. I use these on every deployment to make sure we’re giving our clients solutions that they can depend for performance and reliability. As always, let me know if you have any questions about these tools. Happy testing!

Share this:

Tom Mills from Google and Sean Finnegan from Mozy will be giving an in-depth review of their offerings and how they fit into an agile, post-recession office technology strategy.

I’ll be giving a brief overview of how I think we arrived at this point in IT and what it means for creative, innovative firms that are trying to do more with less.

In an effort to get my thoughts together and get some feedback, I’m using this blog post as a draft for the event.

Let me start off by giving a brief overview of our services, and then a little history about the evolution of our offerings:

We provide a number of technical services for our clients in the areas of infrastructure, application development, and industry-focused workflow consulting. As this is New York, we work with a number of creative firms; media, architecture, publishing, and design companies, as well as some key clients in the financial sector. We strive for long-term relationships with our clients, many of whom we’ve worked with for close to a decade. We have installed and managed hundreds of servers, network devices and application suites, but more recently we’ve been focusing on helping our clients select, migrate to, integrate, and manage Cloud-based services.

Since the 1990s and the introduction of pervasive bandwidth, we’ve gone through a number of permutations of the remote server/client model, and much has been written about the benefits and the irony of the shift back to the mainframe/thin client structure of the 1960s. Now everyone is talking about the future of ‘The Cloud‘; a vast array of computing resources, abstracted and presented as a single source to the consumer.

At the turn of the century, we found most small to mid-sized businesses with a pure Local Area Network (LAN), typically comprised of in-house mail – most likely Exchange – and a few other local services: file, print, etc.  A lot of these firms had an internal IT staff or a dedicated consultant to manage their servers, tape backup, networks, and desktops. Only a few were pushing the envelope by leveraging Application Service Providers (ASPs) to deliver back office services.

The risks with this situation were obvious. These systems mostly depended on a single Internet connection, a single building, and a single individual, prone to career changes and untimely vacations.  Remote access to these in-house services was expensive to do right and applications rarely worked as well remotely as they did in the office.

Over the next five years, we saw a gradual shift towards ‘Hosted Applications’. This typically came in the form of a service provider taking a LAN-based solution like Exchange or SharePoint out of the office and putting it in a data center. In conjunction with this change, we saw the IT services industry begin to shift its focus from in-house IT, or consultants, to managed services – companies providing regular systems management remotely.

There were some benefits to this offering: critical applications were not dependent on intermittent Internet connections or over-heated server rooms. Flaky consultants were traded for predictable management services and cost became as regular as the electric bill.

But there were still problems. We had the same old model of doing things, only it was moved out of the business’s office and into the provider’s.  Services that were built for an onsite installation and LAN speeds were shifted to a remote location – not always producing the best results. Access to applications designed for the LAN was sometimes unacceptable because of bandwidth and latency. In a similarly narrow view of the problem, Managed Service companies focused on monitoring systems and patching software, maintaining the status quo, without looking at the big picture, or driving the business forward.

Now the next generation of IT services is coming along and delivering on the promise of on-demand, scalable solutions. These services are web-native, built for the Cloud and multi-tenant environments.

As services like Google Apps and Mozy were built for the web – not re-purposed LAN applications – they deliver exceptional performance and remain very flexible. Control Group has designed our support and project services in a similar way. Our services are built to function efficiently remotely – scaling up when our clients need it, and going away when they don’t – and also to be flexible and innovative, driving business forward rather than maintaining the status quo.

Using the cloud paradigm, we act as a single source of technology for our clients. We help them run more efficient, profitable businesses by weaving an ever growing selection of web-based services, traditional IT, and industry expertise together, to provide an flexible, competitive business platform.

Share this:

bonnie++ is a series of file system tests that focuses on small files. It was designed to behave like a mail server does, creating and dealing with lots of small files (emails). bonnie++ is easy to run and outputs a CSV file that you can view with something like Excel. With the bon_csv2html command you can quickly generate html pages from the CSVs.

Here’s the output from bonnie++ running on a server:

The HTML output of bonnie++ on a Linux Server

At first glance the output can seem quite cryptic, but if we look close we can see that this provides us a great amount of information about latency and speed on different filesystem operations. I generally run this several times as I make changes to verify that the storage is providing the right performance characteristics. Tweaking a file system to make file system operations happen a few milliseconds faster may seem ridiculous, but in some environments it can make a huge difference.

Next time I’ll post about a tool that’s new to me but can test a disk in so many different ways I’m planning to run it on every system we install from now on.

Share this:

Your Data Here

I was having a conversation recently with one of our consultants, David Rocamora, as our team broke down the contents of a start-up’s data center, when I came to the realization that we may have built our last data center.

Now we don’t really build data centers, but we have racked a lot of servers, storage and network gear around the world in tier 1 data centers for our clients. With the change in the economy and the maturity of several cloud services, the data center that we know and love looks like it’s going the way of the wood pulp newspaper.

Certainly more data centers than ever are being built: Google, Microsoft, Apple, and Amazon are soaking up gigawatts (petawatts?) of power like never before. But the days of dressing down in jeans and a sweatshirt and going out to New Jersey or Colorado to rack servers in an earsplitting, freezing cold warehouse of caged servers and blinking lights seems to be drawing to a close.

Some numbers to consider:

This ‘scaled down’ dot com we were consolidating, had spent about $500,000 on a few racks of some amazing equipment (Sun, Check Point, etc) only to find out 4 months later they didn’t need it. Pennies on the dollar. The contract for the floor space, power, and bandwidth goes on for another 8 months and I bet you could buy a modest BMW for what it’s costing them.

Now a similar sized start-up we just started working with on a really innovative interactive image platform, is using the Amazon cloud and RightScale and is spending about $50,000 a year on cloud services. No capital outlay.

Flexibility?

The cloud is infinitely more flexible, we can put servers in Europe in a matter of minutes, set up high availability zones in different regions around the country, and if they start to get swamped with business like we think they will, we’ll be able to turn up as many servers as they need in a few minutes time.

What if the dot com of 4 months ago took off? Order servers, spend capital. Put in a request for more bandwidth, more cage space. Days, maybe weeks go by. Then get out the jeans and sweatshirt and head over to the data center. Earplugs. Man, those servers are loud.

You get the picture. But this is happening so fast it’s amazing. Six months ago when the dot com was building its data center, the Amazon cloud was still in beta, with no SLA, and it wasn’t an option for a serious start up. Today, building a data center isn’t an option for a serious start-up.

Now we have availability zones, provisioning and monitoring tools, the ability to drop terabytes of data into the cloud — shipped through FedEx! But the real promise is the rich API and the spirit of community innovation. Companies like RightScale are finding a niche in the cloud, developing something really valuable, and then selling it as a simple service that makes our lives so much easier.

It’s exciting to see this happen so fast.  To avoid being crushed by this wave, as an IT team, you need to really stay on top of it. IT in our part of the ecosystem is becoming more the art of selecting, deploying, integrating, managing and supporting cloud based services, and much less the craft of building serious web infrastructure.

It’s a little sad for the hardware geek in all of us, saying goodbye to the roar of the servers, putting down the Velcro ties and picking up some slick provisioning and automation scripts. But I think we could get used to deploying 50 servers in a few keystrokes from a quiet, comfortable seat in the office.

Share this:

I do some work on implementing storage systems for our clients, and we’ve found that different applications have different storage requirements. For example a video post production facility — like the facility at WWE — generally needs lots of disk space that is very good at reading and writing large files at high speeds. The storage here needs to provide good streaming throughput, because high quality video files generally have high bit rates, and are being stored or played back from the disk in real-time for ingesting, editing, or playout. If the storage system is not fast enough to read or write the file in real-time, frames will be dropped. This can cause unsatisfactory media files, programs to crash, or audio and video to become out of sync.

10,000 RPM SAS disks. That's some serious storage.

Suboptimal read/write performance can become a huge problem. When we put in a new system this is something we need to test. I usually do the test with a tool called lmdd.

lmdd comes from the lmbench tools which are provided by Bitmover for benchmarking systems. lmdd is great for testing streaming bandwidth. In most of our engagements with video, we install a Stornext or Xsan filesystem so we’ll run our tests against this. lmdd will probably work on any filesystem that you can mount on your Mac or Linux computer (Leave a comment if you need a version for Mac OS X, I have one compiled).  lmdd lets us verify exactly what the maximum number of megabytes per second we can push through the storage and point us to where we need to make changes to the hardware or software configuration. I use lmdd like this :

lmdd of=/path/to/test_file count=1g

lmdd if=/path/to/test_file

The first tests write performance and the second tests read performance. More information about the syntax is available in the manual page for lmdd. The results of the command from a server I was testing looked like this:

2147.4755 MB in 6.8003 secs, 315.7914 MB/sec

lmdd is great because it’s easy to read. This result shows I could write to the filesystem at 315 megabytes per second. That’s really fast! This is from a test with a server with a lot of RAM and a special filesystem that took advantage of that cache. When I run it on my Macbook, I get a result like this:

18342.6171 MB in 376.7685 secs, 48.6841 MB/sec

So the next time you’re interested in how your storage is performing give lmdd a shot and let me know how it goes. If you’re looking for more information about storage performance testing then stay tuned; I’ll be posting about testing storage with tools that benchmark small reads and writes next.

Share this:

We’ve got a real treat for you today folks. Thanks to the tireless work of our expert trackers, we’ve managed to photograph the elusive North American Server Room Gator (Alligator Servus). We’re not the first to find her though as she’s been tagged for tracking purposes.

Alligator Servus spotted in the wild. Note the detailed labeling.

At 1’1″, she’s a healthy beauty. Apparently she’s pregnant since it looks like she’s nesting on her traditional nursery, the autoloader. Be careful though, they tend to be rather vicious when with young. Hopefully she’ll be able to hunt down enough snack food remnants to raise a healthy brood.

Share this: