I think you actually mean OSI (the Open Systems Interconnect). I remember having to deal with that to get DECnet working across multiple networks, including X.25. Fun times trying to remember the correct NSAPs...

It's quite easy to use, comes with your laptop and provides good copy and paste between the equations that you are entering and other applications. The downside is that the library of functions isn't that complete since it's orientated towards actually producing graphs. As with everything, I guess it depends on what you are doing...

It can be found in /Applications/Utilities/Grapher.app.

This is basically how Time Machine works. Don't forget that the poster is using Final Cut, which means that he is using Mac hardware. Even though there is a Drobo in the backend, depending on how that is connected into the environment, a Time Machine backup will do exactly what you've laid out here. For online replication over distance, just use rsync over ssh, making sure that you preserve all the hard links. Mac OS X already has done the heavy lifting working out what needs to be saved, so you can just copy the backup volume.

Recovery off that volume couldn't be easier too. Just rebuild a server at the remote location and connect up the Time Machine remote backup and you then can just copy data off, knowing that you got the latest version of your environment at about roughly two hours before it got hosed. In fact, worst case would have to take into consideration the lag between the new data being written and copied over to the Time Machine volume (Time Machine runs every hour and I'm assuming about an hour for moving large new video files over to the backup volume), plus whatever the time taken is to copy the data across your pipe. I would make a SWAG at you being okay up to about two to three hours out of sync, although you really need to test the hell out of this setup to guarantee recovery.

Finally, you may want to consider archival copies of your data and purge from your main online repository. Once something has been broadcast, "freeze" it and dump it too a near or offline archive. For something that will be more user friendly, although more complex to setup, you should have something like everything broadcast for the past seven days "online", the past month on "near line" and the rest goes onto tape archived somewhere. Of course, depending on the volume of data, type of requests for older information, frequency of requests, etc you should change these values as appropriate.

This sounds like a fun project!

You've just described a large part of what I did at my last place of employment. My job title included a lot of nasty buzzwords to get HR to pay me a reasonable wage, but basically it entailed me designing large scale system and storage environments.

A lot of people wondered why myself and a colleague went to so many meetings. The reason was that periodically, there would be a meeting about a new business requirement which meant that, for example, we needed to perform 5 billion transactions a seconds and the system should never go down. After a (fairly short) series of meetings with the business and business analysts, a couple of development VMs, a production cluster and a DR system was purchased for a fraction of what they originally budgeted.

Basically the majority of my role was to trap this type of stupidity early enough in the cycle so that it wasn't a major political hurdle in getting things changed. Now that I left, I do actually wonder what kind of things are now getting approved...

-jax.

OpenVMS needed PAKs for the number of interactive users, networking (especially DECnet Phase IV/V routing), clustering, volume shadowing and probably a bunch of other stuff. These were not additional bits of software but included in the core OS. As an indication of how much DEC valued these components, the clustering code (CNXMAN) is NOT included with the source license, although DEC claimed patent issues.

For example, the cost for unlimited users and clustering (the MCOE stuff in modern, HP terms) was EXTREMELY expensive, so much so that not only was the software more expensive than the hardware in some cases, but resale value was almost zero without the original PAKs.

Enterprise features: if you can't afford them, you aren't doing something important enough to need it. That's how the University's got screwed back in the early 90's...

You are correct in what you say, however I don't think you quite mean what you mean. :-)

Here's the real situation: in most large scale enterprise computing environments, those large arrays from the likes of EMC, HDS, HP, IBM, etc are better and reliable. The reasons are varied, but fundamentally come down to the fact that there is real money involved with management and uptime. For most businesses the downtime experienced when server with DAS goes down is inconvenient. In anything like a larger enterprise, any downtime can be easily translated into lost revenue and, in certain circumstances, actual significant losses.

Let me provide an example. Most financial institutions are connected to a messaging network called SWIFT. Simplistically, systems that interface to the SWIFT network are usually money transfer, dealing and other financial applications. You do not want any of those things on DAS systems, regardless of how reliable the underlying hardware is [1], mainly because of things like clustering and replication. Application level replication in these high-volume environments have strict performance limitations and the best way of dealing with these problems is something like SRDF, PPRC or Continuous Access (distance limitations notwithstanding).

This is a specific example in the financial services sector, but you can quite easily find other examples in areas such as manufacturing, healthcare, retail operations, etc. If you are doing your due diligence, it becomes apparent very quickly that the cost of building out the infrastructure is actually small compared with the potential losses you may incur if you don't implement such technology. You can also do the same thing (and in fact it is related) with disaster recovery and RTO/RPO calculations.

In all fairness, this is quite fun stuff. Honestly. :-)

-jax.

[1] The exceptions here are obviously things such as Tandem and mainframes, however mostly these are either connected to their own proprietary versions of SAN-based storage or, in the mainframe world, use FICON. The latter is basically Fibre Channel anyway and is integrated almost as such in most environments (eg Cisco MDS switches with FICON interfaces connecting to an EMC DMX).