As mentioned on HN previously, B&H (a large New York based photography store) do not take online orders in accordance with Jewish holidays.
A Brief History of High Availability
11–20 of 40 posts
Re: A Brief History of High Availability
#12Claiming that "high availability" started with the internet seems to ignore the role that Telcos (Bell Labs?) have played in our field and modern technological world. The engineering work to deliver five nines of availability for POTS shouldn't be omitted in a piece about the history of HA, in my opinion.
And telcos did that with much weaker hardware than is available today!
Weaker in terms of processing power, but the robustness of telco hardware up until the mid-80's is ridiculous - over-engineering was the rule and did deliver excellent availability, though at high cost.
Re: A Brief History of High Availability
#13Claiming that "high availability" started with the internet seems to ignore the role that Telcos (Bell Labs?) have played in our field and modern technological world. The engineering work to deliver five nines of availability for POTS shouldn't be omitted in a piece about the history of HA, in my opinion.
I think it's ignored because the story is focused on databases' HA. My impression from my limited telco experience (correct me if it's wrong) is that there was not much "database stuff" happening in telcos back in the days: only dispatch tables and call duration records come to mind. With then prevailing post-call billing, I assume a lot of the hard constraints on consistency were not there.
Banks and telcos both had database systems that had zero downtime in 20 years, in some case. Tandem Non-Stop was very real - https://en.wikipedia.org/wiki/NonStop_(server_computers)
Re: A Brief History of High Availability
#14Hmm, I think potted history is more correct... There is no mention hardware here. HP, Compaq, IBM and Sun all produced hardware with HA ability. Meaning that normal software could be run on two or more nodes, and should one break, it'd fall over with no loss of data, or outages. Here is a (contrived) video where they literally blow up a server stack: https://www.youtube.com/watch?v=qMCHpUtJnEI You can do this with VM…
IBM has done a huge amount in this area e.g.
Re: A Brief History of High Availability
#15The article mentions sharding (a scaling technique, not exactly something that helps with HA), but then it stops. Does every node in CockroachDB store all data?
No, data in the tables is sharded into blocks and each block is replicated across the cluster using Raft consensus.
Re: A Brief History of High Availability
#16Earlier quoted context omitted.
I think it's ignored because the story is focused on databases' HA. My impression from my limited telco experience (correct me if it's wrong) is that there was not much "database stuff" happening in telcos back in the days: only dispatch tables and call duration records come to mind. With then prevailing post-call billing, I assume a lot of the hard constraints on consistency were not there.
Banks and telcos both had database systems that had zero downtime in 20 years, in some case. Tandem Non-Stop was very real - https://en.wikipedia.org/wiki/NonStop_(server_computers)
They still are :D
Re: A Brief History of High Availability
#17Claiming that "high availability" started with the internet seems to ignore the role that Telcos (Bell Labs?) have played in our field and modern technological world. The engineering work to deliver five nines of availability for POTS shouldn't be omitted in a piece about the history of HA, in my opinion.
I think it's ignored because the story is focused on databases' HA. My impression from my limited telco experience (correct me if it's wrong) is that there was not much "database stuff" happening in telcos back in the days: only dispatch tables and call duration records come to mind. With then prevailing post-call billing, I assume a lot of the hard constraints on consistency were not there.
Custom cameras and mechanical counters at one stage I believe.
Though telcos have much higher standards when it comes to the network / exchanges major failure's where meant to never happen.
Re: A Brief History of High Availability
#18Hmm, I think potted history is more correct... There is no mention hardware here. HP, Compaq, IBM and Sun all produced hardware with HA ability. Meaning that normal software could be run on two or more nodes, and should one break, it'd fall over with no loss of data, or outages. Here is a (contrived) video where they literally blow up a server stack: https://www.youtube.com/watch?v=qMCHpUtJnEI You can do this with VM…
Hey, for once my former life designing HA infrastructure is actually useful!
The reality is that hardware HA was almost always terrible. Of the platforms you described:
- Sun had no hardware HA ever, down to the unfathomable design that all of their E-class machines had only one power cord. They had SOME hotswap hardware, but the rules were byzantine - it couldn't be the first processor board, and it couldn't be the last processor board, oh and by the way, if a processor or RAM went bad, the machine would crash, but when it came back up it would take the bad processor offline and if you were lucky enough the bad processor wasnt on the first or last board and then you could hotswap it.
- The only HA hardware from IBM was the mainframe, and even there, it was definitely possible for a software fault to take down the entire thing. The P-series boxes had lots and lots of fancy sounding HA capabilities, but they would only certify a configuration as fault-tolerant if you bought two of them and clustered them with HA/CMP (i.e. software HA).
- Compaq had the NonStop servers, based on the Tandem acquisition. As the downthread comment correctly pointed out, there was a ton of hardware redundancy in that platform, but I think it ran a proprietary OS. They also had their OpenVMS clustering, which offered amazing HA - but it was all delivered in software, and your app had to be either a) stateless or b) cluster-aware
- HP bought compaq, but the HP-UX machines relied on software for their clustering.
This all dates back to when people thought servers were special in some way, and needed to justify their insane price points with all sorts of fancy marketing features. Some were useful (I remember an early IBM linux box with RAM mirroring that actually kind of worked), but in the end, a Veritas cluster of decoupled nodes almost always worked better, more reliably, and faster than any hardware nonsense.
EDIT: fixed my wrong assertion about Compaq tech.
Re: A Brief History of High Availability
#19HA was a thing long before "the internet" on mainframes, and still is. And apart from sharding, there were, and still are, load balancers for your service tier and HA (redundant, replicated) shared-disk DB clusters from Oracle and others around 1990 or earlier.
One word: "airlines".
Re: A Brief History of High Availability
#20Hmm, I think potted history is more correct... There is no mention hardware here. HP, Compaq, IBM and Sun all produced hardware with HA ability. Meaning that normal software could be run on two or more nodes, and should one break, it'd fall over with no loss of data, or outages. Here is a (contrived) video where they literally blow up a server stack: https://www.youtube.com/watch?v=qMCHpUtJnEI You can do this with VM…
Hey, for once my former life designing HA infrastructure is actually useful! The reality is that hardware HA was almost always terrible. Of the platforms you described: - Sun had no hardware HA ever, down to the unfathomable design that all of their E-class machines had only one power cord. They had SOME hotswap hardware, but the rules were byzantine - it couldn't be the first processor board, and it couldn't be the…
"Compaq had the NonStop servers, which ran OpenVMS...but it was all delivered in software"
NonStop/Guardian had nothing to do with OpenVMS. And the hardware was certainly purpose built for HA, including redundant, lockstepped CPUs, disk controllers, etc.