This page contains a Flash digital edition of a book.
18 TVBEurope Archiving & Storage Long term storageclouds


Why form an archive cloud in the first place? Howard Twine, product manager, SGL, offers an insider perspective on broadcast archive management middleware


THE CLOUDS that are currently drizzling over the broadcast technology landscape are really only dealing with small amounts of data. Metadata and graphics appear to be the real starting points for this change in workflow, but as more content is created and consumed the requirement for longer term, more generic repositories increases. Not so long ago, a broadcast


archive was bespoke. It could only hold certain types of files, and the archive and restore processes were hard coded between each system connected. It was not uncommon for only one system (eg playout automation) to be connected to the archive. Recently, a more distributed


approach has been adopted. Those building an archive for playout are over-specifying the hardware required, not just to cope with normal organic growth, but also with a view to opening up the archive to other departments. One reason for this shift is the implementation of improved mechanisms that exist within archive management software for content organisation.


Now, virtual partitions can be


created within different tiers of storage, each assigned to different systems; for example it is relatively common for one archive to service playout transmission, production, news and graphics. All departments


that can grow and be widely shared. This remit falls firmly on the shoulders of the archive management solution; commonly referred to as middleware, without this layer a cloud for long-term storage simply cannot form.


whether locally or remotely to provide system resilience. However this only works when heterogeneous storage can be presented to the outside world as one virtual storage entity. This is where cloud storage comes in.


the archive management system is the automatic migration of content between storage tiers. Not all facilities own dark fibre


have their own specificworkflows and tools, but through careful planning and versatile interfaces all this can be achieved under the same private cloud.


Bandwidth issues Physical storage media have also become more diverse. Today’s choice of disk storage is massive, and tape libraries are highly scalable. However, none of these individual storage solutions alone can form a true broadcast archive


Why form an archive cloud in the first place? To answer this, one needs to look at storage types and the reasons that people choose them. Disk storage for archive is usually selected for fast access to offline content, on the basis that high-speed, high-cost on-line storage is probably being used for collaborative editing, current projects, etc. There are significant


advantages to adding a tape library to archive disk storage,


With the application of simple


web-style APIs content can be moved into a generic ‘archive’ without the controlling system having to know if it’s going to disk or tape, locally or remotely. It’s still important that the API supports the concept of specific storage locations within the archive, but these archive groups can be used as virtual containers to segregate different content, and different migration rules can be applied to them. The value of


capable of faster-than-realtime transfers right up to the doorstep. Obviously for hosted services (the remote cloud) video tapes can be transferred. However, this still requires that the service provider has the infrastructure and skill-set required to ingest and tag the content, and introduces another level of complexity when ensuring that remotely ingested content can be accessed through its corresponding metadata. From a disaster recovery perspective this approach duplicates effort. However, the technology does exist to move bulk quantities of content plus metadata as files relatively inexpensively. One such technology is LTFS. This standardised approach of writing data to LTO-5 (and upwards) tape provides a viable method of transferring bulk content into and out of a storage cloud. For example, a playout facility


News Room RunDown creation Embedded NLE & Text Editor Wire management RunDown playout


Your Team For Broadcasting Solution.


Mam


Asset Life Cycle management Powerful Full Text search engine Tape Library management


Traffic Spot, Promo & Commercial Right management Daily and Weekly playlist


Automation


Capture & Playout Embedded Logo and CG Device management


migrates content into the archive on site as normal, i.e. ingest from videotape and QC before moving to on-line playout storage or copying directly to the archive. Once in the conventional archive domain, migration rules copy the content to an LTFS ‘export’ tape (or group of tapes, where required). Any metadata is archived along with the content. Alternatively, MXF wrappers like AS03 or AS11 (AS02, etc, for production related workflows) can be used to encapsulate the content and its metadata, ensuring safe passage of all necessary information. Once full, the LTFS export tape is removed from the library and posted to the remote cloud storage facility. On arrival in the ‘cloud’ the


We Know How To Do It Servizi informatici srl - www.si-media.tv - Tel +39 0423 750075


LTFS export tape is inserted into the library. The archive management system scans the index at the header of the tape (as opposed to reading all 1.5TB of data on the tape), and populates the archive management software database with the necessary information about the content. Now that the content is available, any systems connected to the archive cloud can query the archive database to find out what is new (or receive ‘push’ notifications of new arrivals) and access the content. This approach ensures that the systems closer to the business process rules remain in control of the content.


www.tvbeurope.com June 2012


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52