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.
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...
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).
We decommissioned a large number of ancient DEC and IBM SSA storage arrays that we just kept adding storage to. It was simply a cost-avoidance situation. As the business grew, they needed more storage and to do that we had a choice: spend huge amounts of money on storage that was old and needed expensive upgrades (more shelves/frames), or consolidate down into a single array with reallocatable storage.
Talking in rounded, rough numbers (as I can't remember the details -- this was about four years ago), a new SSA frame on the IBM side and additional storage on the DEC side would cost in the order of $100k. The new array came in at around the same cost. During the migration we consolidated filesystems between the various platforms so that, for example, the 100GB needed on node A went down to 50GB since that was all it needed. Repeat that across all filesystems and all SAN-attached systems and all of a sudden you can easily reclaim a huge amount of space.
Of course, I can't go into exact details due to confidentiality issues, but these types of savings are real in certain situations. As always, your mileage will vary, hence why you need to do a thorough analysis up front.
Someone else replied to this more eloquently than I, however the problem is basically to do with performance. For the majority of real world workloads, a distributed model like the one you are proposing just does not scale. There's a network bandwidth issue. You are just moving the cost from the storage to the network.
I disagree with this and face this question all the time in work. Disks are cheap, storage systems aren't. If this is for a business that requires reasonable uptime, then the only solution would be to implement a SAN using Fibre Channel or iSCSI and then take out the drives. With the right array, all of a sudden those drives become superfluous (you decide if boot from SAN is right for you), management is easier and you'll be able to get a lot of reuse out of the drives.
Now a lot of people will start to question the cost of doing all of this and it isn't cheap, however you have to analyze the data correctly. We migrated 200 servers from DAS to a SAN and had our money back within 12 months. Add on top of that the implementation of VMs, all of a sudden those 200 went to 20. That's a big difference in cost of ownership.
As someone who attended LinuxWorld on behalf of my corporation, I can let you into a little secret: companies really want to run Linux; they just need the support and services around it before it can be deployed. When I talk to my CTO and CIO about the benefits of Linux, they listen and they agree that it is a cool thing. The problem historically was that I couldn't provide the same solution that I can with either a proprietary UNIX or Windows. This is now changing (although there are some hurdles).
To the people who think that my attending LinuxWorld indicates something bad, you should definitely think again. It is precisely the adoption by large corporations that are going to make Linux succesful across the mainstream.
Slashdot Mirror
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).
We decommissioned a large number of ancient DEC and IBM SSA storage arrays that we just kept adding storage to. It was simply a cost-avoidance situation. As the business grew, they needed more storage and to do that we had a choice: spend huge amounts of money on storage that was old and needed expensive upgrades (more shelves/frames), or consolidate down into a single array with reallocatable storage.
Talking in rounded, rough numbers (as I can't remember the details -- this was about four years ago), a new SSA frame on the IBM side and additional storage on the DEC side would cost in the order of $100k. The new array came in at around the same cost. During the migration we consolidated filesystems between the various platforms so that, for example, the 100GB needed on node A went down to 50GB since that was all it needed. Repeat that across all filesystems and all SAN-attached systems and all of a sudden you can easily reclaim a huge amount of space.
Of course, I can't go into exact details due to confidentiality issues, but these types of savings are real in certain situations. As always, your mileage will vary, hence why you need to do a thorough analysis up front.
-jax.
Someone else replied to this more eloquently than I, however the problem is basically to do with performance. For the majority of real world workloads, a distributed model like the one you are proposing just does not scale. There's a network bandwidth issue. You are just moving the cost from the storage to the network.
-jax.
I disagree with this and face this question all the time in work. Disks are cheap, storage systems aren't. If this is for a business that requires reasonable uptime, then the only solution would be to implement a SAN using Fibre Channel or iSCSI and then take out the drives. With the right array, all of a sudden those drives become superfluous (you decide if boot from SAN is right for you), management is easier and you'll be able to get a lot of reuse out of the drives.
Now a lot of people will start to question the cost of doing all of this and it isn't cheap, however you have to analyze the data correctly. We migrated 200 servers from DAS to a SAN and had our money back within 12 months. Add on top of that the implementation of VMs, all of a sudden those 200 went to 20. That's a big difference in cost of ownership.
As someone who attended LinuxWorld on behalf of my corporation, I can let you into a little secret: companies really want to run Linux; they just need the support and services around it before it can be deployed. When I talk to my CTO and CIO about the benefits of Linux, they listen and they agree that it is a cool thing. The problem historically was that I couldn't provide the same solution that I can with either a proprietary UNIX or Windows. This is now changing (although there are some hurdles).
To the people who think that my attending LinuxWorld indicates something bad, you should definitely think again. It is precisely the adoption by large corporations that are going to make Linux succesful across the mainstream.
-jax.