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

Architecting for Uptime

blog.serverfault.com

Post reply on HN
Print view View original

11–15 of 15 posts

Re: Architecting for Uptime

#11

Post by gizzlon »

dpdp_ wrote: post #2

There are so a lot more patterns of high availability architectures other than load balancing. Distributed Queues, Pub/Sub, Gossip just a few that come to mind. In your example, you are using what is called a classical three-tier web architecture - a Load Balancer + Stateless Nodes + Scalable Storage. The most interesting part of HA setup in a three-tier web architecture is HA setup of the persistent storage componen…

A handy summary of different solutions:

PostgreSQL: Comparison of Different Solutions http://www.postgresql.org/docs/current/static/different-repl...

as well as the rest of chapter 25..

Re: Architecting for Uptime

#12

Post by petergrace »

sausagefeet wrote: post #9
trustfundbaby wrote: post #8

Earlier quoted context omitted.

So should they not have posted at all or should they have used a different title?

If your article on how to architect for uptime ends with how the authors system isn't architected for uptime I don't think they should have written it. How do we know their advice applies once they actually institute the changes they talk about?

This is a really good point and I appreciate your viewpoint, but just because I wrote the article for/about stack exchange it doesn't preclude me from having done it differently at a prior employer.

Re: Architecting for Uptime

#13

Post by petergrace »

dpdp_ wrote: post #2

There are so a lot more patterns of high availability architectures other than load balancing. Distributed Queues, Pub/Sub, Gossip just a few that come to mind. In your example, you are using what is called a classical three-tier web architecture - a Load Balancer + Stateless Nodes + Scalable Storage. The most interesting part of HA setup in a three-tier web architecture is HA setup of the persistent storage componen…

Excellent points! You're quite right that there are a lot more things we could do to improve the high availability in the Stack Exchange environment. Unfortunately, I was hired well after the environment was designed so any suggested changes would need to not only pass the rigors of review by the team but also be able to handle the load that stackoverflow.com generates. Changing pieces at this point would be nontrivial and difficult to get approval on if it meant that we'd affect performance of our main property.

That being said, I'm 100% in agreement with you that the two options you supplied would be wonderful additions to our environment.

Re: Architecting for Uptime

#14

Post by sausagefeet »

petergrace wrote: post #12
sausagefeet wrote: post #9

Earlier quoted context omitted.

If your article on how to architect for uptime ends with how the authors system isn't architected for uptime I don't think they should have written it. How do we know their advice applies once they actually institute the changes they talk about?

This is a really good point and I appreciate your viewpoint, but just because I wrote the article for/about stack exchange it doesn't preclude me from having done it differently at a prior employer.

Talk about that then? It make it clear you're not just talking out your tush some way?
Post reply on HN