Eric Cox
Forum Replies Created
-
Playbox will run on the PC and will utilize a blackmagic card. However, I believe they are no longer supporting software only installations. Mostly as a favor I support a few installations on some Intel SR2500 hosts which are configured to run redundantly. This setup also uses a third host to serve a network dongle service. It was terribly affordable mostly because I picked up tons of cheap spares kits on ebay to build the hosts and we purchased before the price hike on the software. We had some rough days until I changed out the stradis cards for black magic units.
My experience has been that cost typically aligns well with stability. I’ve had a lot of punishment from those who hold the purse over the years.
Another issue is a system may appear stable until you introduce a certain hardware/software combination. I was fairly picky to replicate the solutions that were offered at the time, but I have had many turn key solutions which need a good deal of care to make mostly stable.
Thus my advice is that if you can afford it a vendor supported solution is always the best route to go. Thus the reason I recommended taking Bob’s advice.
I know a few more packages out there, but I have forgotten their precise name. I also have a hatred for said solutions so I’m kinda glad I forgot them. (I’m so jaded!)
-
sync goes everywhere!
I cannot recall if the blackmagic device will automatically use the sync input. Make sure you check the application to ensure that if a sync option is available that it is enabled.
The same can be said for the deck as I have seen some which did not automatically enable the input or perhaps some nefarious individual disabled the option.
-
There are a number of PC solutions and they are typically very low end in my opinion. There are also a number of embedded devices which will accomplish the same goal, but they tend to be closed box with regarding to automating.
Do you have a rough idea on the budget for this particular task? I always remember asking that question and the answer was typically as cheap as possible. (SO I wouldn’t get an exact figure due to the fear that I might spend it all!)
Bob is also usually spot on when it comes to balancing cost and performance though.
-
Ultimately, you are not just purchasing hardware from a prefab shop, but rather you are purchasing a support contract.
If you have to ask the question of why should I buy one of these guys and not build it for half the cost then you probably shouldn’t be building it.
For me I could very well build a very large array, make it fast and be quite capable of troubleshooting it if there are issues. (I do it all the time with in house farms and vendor gear) What I cannot do is guarantee that the components won’t work bug free out of the box. In fact, without a lengthy test cycle or simply recycling someone elses design there can be any number of issues. Even recycling the core components of a known design it’s not guaranteed to have some random devastating bug crop up weeks later that might corrupt random data. (Hello HP drive cache bug) To be honest, if you don’t have a very close relationship with the vendor you are only going to hit front line support which is composed mostly from zombies and shrubberies.
While at first glance it might seem storage vendors are the sum of the hardware they provide this is in actuality not even remotely close to their best offerings.
Now that said… these things are only as important as your data so if you can afford to lose it then goto town. It’s a fun and exciting world in the storage world, but do be prepared to spend some late nights learning.
-
Defies logic doesn’t it.
I have million horror stories both from small organizations and corporate america. It’s a lot easier to look back and laugh now then when those incidents happened.
-
I deal with large farms many many times larger with systems that have to perform and where data loss means more money then the rack costs. I do however have a few friends who are quite on a budget with their production shops. While I moved on from that engineering work a while ago I still work gigs for them in my spare time. Sadly, I know the pain you are talking about.
The problem with being on a budget isn’t the budget itself. You can come up with scenarios all day to help someone. However, it’s when being “cheap” causing data loss that the customer has to pay to recover from. (If possible).
Funny how you mention someone ignoring the drive light. I had a group who had ignored the drive failure light on the host. However, I had enabled the audible alarm on the controller and of course it went out blaring. They managed to actually fire up the software and disable the alarm. Completely ignoring the disk failure issue! The system actually emailed out the failure as well, but the technician they had previously was no longer working there. To add even more insult to injury the disk that was in the hot spare bay was removed and presumably re-purposed to someones home.
Surprisingly, I did recover the array and start the rebuild, but it was more luck as the second failed disk came back online.
As someone who likes to live in fantasy land I will always preach data protection. If someone wants to go the cheap route then the loss is ultimately upon their head. However, I don’t believe I can truly express how fragile drives tend to be. It’s not some evangelical crusade either. I have been there when the data loss and recovery was on my head. It’s not a good feeling and it’s probably worse for the customer.
-
Latency is going to suffer with larger stripe sizes. The is simply because the head has to read the full stripe before moving onto the next batch of sectors. Large stripes are typically used where you need increased throughput on large linear reads.
If you need increased latency, which typically benefits smaller non-sequential reads, you would opt for a lower stripe size.
Ideally, if you know you will be doing large sequential reads with a large stripe size it helps to align the file system block size. With read ahead and a large cache it’s not such a big deal, but you can eek out some nice performance if you plan accordingly and known the data content.
-
You can do a raw fcp path with no management software. However, typically this management software is intended to dealing with multiple paths for redundancy. You can’t do that with with Ethernet without an expensive set of switches which have the fail over capability. Which is not something you are going to see on a low end switch.
The other issue with traditional ethernet is the performance gaps from the stated maximums. Not only do the more affordable cards rarely actually achieve their theoretical maximum, but when dealing with the layer 3 side there is protocol overhead.
Ethernet is ok and the protocols which stand on top to emulate storage are not bad either. However, there is always going to be overhead which makes it less then ideal. It’s not so much the copper, but the philosophical differences between their implementation.
When dealing with bonded links it’s important to remember that it’s not truly a single pipe. An LACP link is going to have a packet transmission path based on whatever sort mechanism you choose. (Typically source/destination hash). This means that while the bonded link might appear larger there is going to be a throughput limit between the same source and destination equal to the smallest link in the aggregate. It may or may not be a problem depending on your use case, but it’s important to be aware of how that bond really works.
So 10GB (which I can do cheaply on fiber today) can do great things with disk networks. However, it’s not going to be as versatile as 10GB E on copper tomorrow. (And really you only do fiber ethernet if you have distance issues or problems with current sink due to negative ground potential difference)
-
However, none of the converged implementations are what I would like to call terribly stable nor would they be considered to have a full backplane. I’ve seen and demoed all of their gear at this point as well as full customer testimonials on how much they hate it.
Some of the stuff coming down the pipe from some vendors will let you retrofit a rack and plug in their provisioning software. My money still tends to stay on stability over features.
-
Don’t do RAID 5 on multi-terabyte volumes. Even if the array has hot spares available this is asking for issues. The problem being that the potential for a misread while rebuilding from parity is now so great that rebuilds can fail. The read error rate has remained constant, but we have scaled disk sizes up dramatically from the days of raid 5’s inception.
At this stage nearly everyone has a RAID 6 implementation or something similar based on some proprietary protocol. Sure, you lose another disk worth of space to parity, but the storage is still superior to RAID 10. Even in degraded mode when data is being rebuilt on the fly is not nearly the hit it was due to the additional parity stripe.