From Steeple

Contents 1 Summary 2 Background 2.1 An introduction to Podcast Producer 2.2 Institutional Podcasting at Oxford

[edit] 1 Summary

In order to setup a central podcasting service for your institution, you will need a sensible, resilient, stable architecture and processes that can be supported, most likely, within current staffing levels. The systems currently in place may no longer be adequate to the demand you will face and, although they will no doubt exceed expectations in the short-term, the common temporary ad-hoc solutions used to meet external targets for launching something like iTunes U tend to require a high degree of costly manual interaction.

In this document, we outline implementing a minimum recommended architecture for an institutional media-processing cluster that will allow efficiencies to be made through automation and risk-reduction. The solution enables support levels that will be sustainable and allows for dramatic growth in quantities of content, with minimal future downtime and smaller expenditure. This strategy is based on Oxford’s experiences and outlines their planned migration to the next generation of Apple Podcast Producer and its deployment as a central university service. This document is based on a report used to secure funding for moving from a pilot project to a full service, and is focussed on the infrastructure needed for that change.

The solution uses a 16-Terabyte RAID box, presented using Apple XSan 2, via a private low-latency Fibre-Channel network, to be combined with new and existing XServe resources. Costing for this solution was approximately £25,000 and is outlined below as the Audio and Video Processing Cluster.

The system provides the minimal foundations for a flexible architecture that can scale up to meet planned usage levels and development work, whilst reducing risks and related expenses with regard data management. This system becomes the lynch pin of the iTunes U publishing model and key enabler for service functionality within the Podcasting Service. The capacity of the system is calculated based on current projections, to meet usage levels for the next 18-24 months, and is essential now as we have already exceeded current capacities in terms of data storage, processing flexibility and application development – a limitation which is hampering our abilities to currently support our modest service levels. The technologies are proven and supported by both Apple Inc and several other HE institutions, and fit within the available support structures offered by OUCS, as well as being the least expensive proven option available.

[edit] 2 Background

This report builds upon the work of the past 18 months in identifying a viable podcasting processing solution and the trial implementations done so far. Over this period, a very labour intensive process has developed to work around the insufficient technical resources to allow the launch of the iTunes U podcasting portal service. This solution uses the Apple Mac OS X based Podcast Producer as the primary encoding engine, a scalable solution that can take advantage of both efficiencies in extra hardware resources, but also provides automation solutions to many of the final tasks involved in publishing podcasts. Whilst Podcast Producer is designed for scalability, several factors determine how easy it is to scale the system and whether it is feasible to perform all the tasks that are required within the system.

The following section is brief overview to the usage of Podcast Producer within the Podcasting Pilot.

[edit] 2.1 An introduction to Podcast Producer

A generic Podcast Producer system for managing the processing and publishing is illustrated in the following diagram:

In this simple example, content (digital media files and related meta-data) is provided to the Podcast Producer system which then creates a series of grid tasks based on a user-defined workflow and distributes these tasks to available processing agents on the Xgrid. Data is held in a shared filestore and accessed directly by each agent as they perform their tasks. Final outputs are then made available to a publishing service (e.g. a web server) and thus served to the audience.

[edit] 2.2 Institutional Podcasting at Oxford

Podcasting has gained a high profile and significant recognition within the University from the Chancellor down. Work has been done to dramatically improve the accessibility and presentation of Oxford’s past efforts in podcasting and provides identifiable portals through which users can locate and download media content from the University. The two key portals are the website (http://podcasts.ox.ac.uk) and iTunes U. Both of these portals rely on many layers of background systems and processes, and whilst the user may see a harmonious, integrated view of podcasting at Oxford, the reality underpinning this façade is far from those ideals. The following diagram highlights the different stages involved in producing these outputs and a sense of scale regarding the work/resources/costs needed at each step.

Figure 1: The Foundations of Institutional Podcasting

If area was to represent the costs in time/money/resources, then this chart should really be more of a column, or hourglass shape to be truly sustainable. Automation and de-duplication of tasks and data will dramatically reduce the amount of service support time currently required, and shorten the height (duration) of time required to travel up this pyramid.

To expand further on the physical workflow that leads to each podcast, we have the following overview diagram.

Figure 2: Overview of the podcasting workflow used in OUCS (larger copy in Appendix)

It is important to note that this diagram is not a linear process and that the arrows represent starting dependencies, whilst the block represent discrete tasks. Also, the starting point for a given podcast is not always the first task on the chart, nor is the exit point necessarily the last task. The entry and exit marks shown in this diagram represent OUCS’ point of view. This diagram also alludes to there being several independent and uncommunicative systems involved in the process, and that currently many tasks fall outside of existing technical systems.

For reference regarding current situation, the following diagram outlines the processing tasks currently employed.

Figure 3: Current OUCS processing workflow (simplified)

Whilst some of this process has been slightly optimised (we presently don’t have any space for an LTG Archive, for example – which means no data resilience), this is in essence what has to be done whilst working with two Mac-Minis, a couple of external hard-drives and, recently, a two-year-old baseline model XServe.