Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tell HN: Server Status

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 124 posts

Re: Tell HN: Server Status

#71

Post by barrkel »

shiftpgdn wrote: post #52
barrkel wrote: post #35

By tolerating the loss of two disks, do you mean raidz2 or do you mean 3-way mirror? Raidz2 is not fast. In fact, it is slow. Also, it is less reliable than a two way mirror in most configurations, because recovering from a disk loss requires reading the entirety of every other disk, whereas recovering from loss in a mirror requires reading the entirety of one disk. The multiplication of the probabilities don't work…

Why not Raid 60 with Btrfs? It'll tolerate two disk loss with pro-active parity protection via btrfs and be faster and provide you with more disk space.

Do you feel comfortable with reliability of btrfs?

When I do a Google search, I want to see confirmed cases of fs lockups / data loss from fs bugs to be multiple years in the past. btrfs isn't there yet.

I like btrfs's ability to e.g. switch raid levels without offlining the array. I think it's promising. But I wouldn't trust my data to it tomorrow.

Re: Tell HN: Server Status

#72

Post by annnnd »

loceng wrote: post #56
makmanalp wrote: post #55

The trend I'm noticing is people mentioning that if only HN was moved to , problems would go away. Instead of doing that, they probably dropped a bit more than a thousand dollars on a box, and are probably saving thousands in costs per year. This is money coming out of someone's pocket. This site is here, and it's a charity, being provided free of cost, to you. Who cares if HN is down for a few hours? Seriously? Has…

Not to discount the value of HackerNews, however there is great benefit to YCombinator being associated with it; They could let it go down and never host it again but they would lose value.

Yes, but I don't think such shortages do them much harm.

Re: Tell HN: Server Status

#73

Post by conorh »

Have you thought about perhaps open sourcing the server setup scripts for HN? I'd love (and I'm sure many others here) to help with the configuration. Perhaps a github repo for some chef recipies that people could work on given the current servers?

Re: Tell HN: Server Status

#74

Post by [deleted] »

yebyen wrote: post #51
gvb wrote: post #40

Earlier quoted context omitted.

No, 2400 baud - phase shifting is used encode the bits, so the actual frequencies used are complex. 300 baud used two tones for Tx and two tones for Rx so it is easy to whistle (albeit the characters coming out are garbage). Higher baud rates are probably impossible to whistle because the encoding is much more complex. I never tried, acoustic couplers didn't work above 300 baud. ;-) Ref: http://en.wikipedia.org/wiki/…

I am pretty sure he meant 2600Hz anyway Besides everyone knows, nobody whistles 2600Hz, they just get the toy out of the Cap'n Crunch box to do it for them. http://en.wikipedia.org/wiki/John_Draper#Phreaking

[deleted]

Re: Tell HN: Server Status

#75

Post by eloff »

shiftpgdn wrote: post #42
eloff wrote: post #28

Earlier quoted context omitted.

The advantage of cloud servers is if one experiences corruption or goes down you just kill it and start a new one. If your cloudy EBS equivalent experiences corruption, you restore from snapshot and off you go again. Either way it involves less downtime than HN seems to have. The downside is it costs more (usually, depends on how high your server management and data center overheads are.) I'd like to point out that d…

You realize cloud services are vulnerable to data loss as well?[1] The cloud isn't some magic machine off in a datacenter somewhere. Its a bunch of servers and SANs just like what you or I would roll out if we needed bare metal infrastructure. The only difference is the extraordinary markup that you're paying amazon to use their servers. [1] http://blogs.computerworld.com/18198/oops_amazon_web_service...

Yes, obviously. That's why I said you should restore from backups in that event. If you lose your backups on S3, congratulations, you had better odds of winning in your state lottery. The big difference is not just the price as you say, but the flexibility.

Re: Tell HN: Server Status

#76

Post by jrmenon »

cincinnatus wrote: post #6

I'm sure it has been asked many times before, but I'd love to hear the latest thinking... Why in 2013 is HN still running on bespoke hardware and software? If a startup came to you with this sort of legacy thinking you'd laugh them out of the room.

FWIW, our start-up began on AWS during early days, but finally due to cost constraints, migrated most of our servers to our own h/w setup. We had substantial number of servers of varying types on AWS (live servers, full hadoop cluseters etc..), on east and west regions, lots of EBS storage etc.., so not some trivial setup.

We really liked AWS, and the support we got for most of the times was good, but as we had 24x7 live traffic, even with reserved instances, the cost finally caught up to justify the move to our own hosting solution.

One thing that the made the migration easier for us was that from day 1, we decided to treat AWS as a co-location, hence we set things up with the usual open-source s/w stack (i.e. avoided proprietary Amazon solutions like dynamo, messaging solutions etc.. maybe just used S3 for offline archiving of logs. It was tempting to build on their components, but ended up building it ourselves.), including own own hadoop setup. When the time came, we could easily migrate things out.

Hope this gives some perspective. Still a fan of AWS, and if I were do another start-up, would follow the same script all over again.

Re: Tell HN: Server Status

#77

Post by KaiserPro »

shiftpgdn wrote: post #52
barrkel wrote: post #35

By tolerating the loss of two disks, do you mean raidz2 or do you mean 3-way mirror? Raidz2 is not fast. In fact, it is slow. Also, it is less reliable than a two way mirror in most configurations, because recovering from a disk loss requires reading the entirety of every other disk, whereas recovering from loss in a mirror requires reading the entirety of one disk. The multiplication of the probabilities don't work…

Why not Raid 60 with Btrfs? It'll tolerate two disk loss with pro-active parity protection via btrfs and be faster and provide you with more disk space.

Raid 60 is not really that good. the rebuild time of a raid 6 slice of 12 disks is 36 hours. (sas 3tb disks)

Raid 10 is more expensive on space, but is the best compromise of traditional raid.

LSI have some fancy magic virtual disk chunking mechanism to make rebuidling large raid 6 luns much quicker (4-8 hours)

Re: Tell HN: Server Status

#78

Post by KaiserPro »

rbanffy wrote: post #69
shiftpgdn wrote: post #52

Earlier quoted context omitted.

Why not Raid 60 with Btrfs? It'll tolerate two disk loss with pro-active parity protection via btrfs and be faster and provide you with more disk space.

They are running BSD. I don't think BtrFS is an option and ZFS can do pretty much every trick BtrFS can. The data corruption on the first machine seems like a hardware problem.

ZFS has inbuild raiding and much much friendlier tools.

The BTRFS tools are like MDAM and lilo had a child.

Re: Tell HN: Server Status

#79

Post by lucb1e »

erkkie wrote: post #32

This reminds me I'm still looking for a (pki?-)encrypted zfs snapshots as a backup service, /wink-wink @anyone Hoping the box has ECC ram, otherwise zfs, too, can be unreliable ( http://research.cs.wisc.edu/adsl/Publications/zfs-corruption... )

Tarsnap?

Re: Tell HN: Server Status

#80

Post by IgorPartola »

cincinnatus wrote: post #6

I'm sure it has been asked many times before, but I'd love to hear the latest thinking... Why in 2013 is HN still running on bespoke hardware and software? If a startup came to you with this sort of legacy thinking you'd laugh them out of the room.

Because it is actually 2014 :)

Kidding aside, running a bare metal server you own or rent is always cheaper, assuming you cannot save money by turning things on and off and know you capacity needs. Sure HN grows but not nearly as fast as FB, Twitter, etc. the service is big enough where it would require expensive virtual servers. This is the best case scenario for a physical hardware box run by people who are familiar with such things.

Post reply on HN