Como a disponibilidade de 24X7 horas para uma aplicação pode ser alcançada?

Question

Fiz esta pergunta em uma entrevista:

Eu tenho um servidor sql e um aplicativo asp.net. Quero disponibilidade de 24X7 horas para meu aplicativo, mesmo se o servidor travar.

Quais são as diferentes maneiras de alcançá-lo no nível do código e no nível superior (ou seja, não no nível do código)?

    

Answer 1

Em última análise, isso se resume a dinheiro. Há um custo para cada 'nove' no mítico 'cinco noves' (99,999% de disponibilidade, 5 minutos de tempo de inatividade por ano), e esse custo é bastante alto. Um sistema de disponibilidade de 99,999% custa em milhões de dólares, e tem que cobrir hardware, licenças de software, pessoal de especialistas altamente treinados, treinamento, procedimentos e assim por diante. Você deve considerar coisas como atualizações de sistema (patches de SO e de fornecedor), atualizações de aplicativos, vários procedimentos de manutenção, como reindexação de banco de dados, etc. etc.

Mas, para uma resposta muito simples, eu indicaria a Visão geral das soluções de alta disponibilidade :

• Failover clustering

Failover clustering provides high-availability support for an entire instance of SQL Server. A failover cluster is a combination of one or more nodes, or servers, with two or more shared disks. Applications are each installed into a Microsoft Cluster Service (MSCS) cluster group, known as a resource group. At any time, each resource group is owned by only one node in the cluster. The application service has a virtual name that is independent of the node names, and is referred to as the failover cluster instance name. An application can connect to the failover cluster instance by referencing the failover cluster instance name. The application does not have to know which node hosts the failover cluster instance.

• Database mirroring

Database mirroring is primarily a software solution to increase database availability by supporting almost instantaneous failover. Database mirroring can be used to maintain a single standby database, or mirror database, for a corresponding production database that is referred to as the principal database.

• Log shipping

Like database mirroring, log shipping operates at the database level. You can use log shipping to maintain one or more warm standby databases for a corresponding production database that is referred to as the primary database. Standby databases are also referred to as secondary databases. Each secondary database is created by restoring a database backup of the primary database with no recovery, or with standby. Restoring with standby lets you use the resulting secondary database for limited reporting.

• Replication

Replication uses a publish-subscribe model. This lets a primary server, referred to as the Publisher, distribute data to one or more secondary servers, or Subscribers. Replication enables real-time availability and scalability across these servers. It supports filtering to provide a subset of data at Subscribers, and also allows for partitioned updates. Subscribers are online and available for reporting or other functions, without query recovery. SQL Server offers three types of replication: snapshot, transactional, and merge. Transactional replication provides the lowest latency and is usually used for high availability.

    

Answer 2

Eu não acho que muitas pessoas aqui lhe darão uma resposta a uma pergunta da entrevista para ajudá-lo a blefar, e tenho certeza de que não é o que você quis dizer, então aqui estão duas opções de aprendizado para você.

• Google "Alta disponibilidade asp.net". ("Alta disponibilidade" é o termo que você está procurando)

• Veja este vídeo

Answer 3

No nível do código, não há muito o que fazer: se o seu servidor travar, ele trava. Em termos de hardware, eles provavelmente estavam procurando por uma frase como Cluster de Failover .

    

Answer 4

Requer vários servidores, o que não é viável para algumas pessoas e pode não ser necessário. No entanto, se for crítico atingir quase 100% de tempo de atividade, há algo conhecido como Cluster de Failover no servidor nível que, quando o servidor falha por vários motivos, um dos seus outros servidores "entra" e assume o controle.

    

Answer 5

VMware vSphere com Fault Tolerance (FT) ou equivalente para outros produtos de virtualização. Esta solução não está limitada a 2 servidores (um falha, o outro suporta a carga), mas pode ser distribuído em vários servidores. É apenas uma questão de quanto você quer gastar.

Isso é completamente independente do sistema operacional, o que significa que você pode ter seu aplicativo em execução no Windows Server e seu banco de dados em execução no Linux RedHat ou vice-versa.

    

Answer 6

Hospedar seu aplicativo asp.net e banco de dados em dois servidores separados com uma opção de hot fall over para ambos os servidores fornecerá maior resiliência, Cláusula de queda conforme sugerido acima fornecerá isso. Mas também é preciso pensar em termos de se o servidor de banco de dados ficar inativo e se o banco de dados for restaurado para que as transações sejam confirmadas de maneira FIFO.

Geralmente expandindo é como eu responderia a essa pergunta, mas eu concordaria com o @CXFX que fazer isso inteiramente em um nível de código é impossível.

    

Answer 7

Em negócios práticos, eu olharia:

• onde eu coloquei o log & do Sql Server arquivos de dados
• as opções de virtualização

Mas esse não é o caso do Stackoverflow.

    

Answer 8

Não é uma resposta rápida, já que é preciso muita aprendizagem do mundo real para realmente dominar a alta disponibilidade em um data center, na plataforma e no nível do aplicativo. Em um nível alto, aqui estão algumas coisas a serem consideradas.

Para ser resiliente a falhas e patches do servidor, você precisará de balanceamento de carga no nível do site, algum tipo de solução de SQL HA e um aplicativo que não esteja bloqueado em um único servidor.

Para o nível do site, há muitos balanceadores de carga de terceiros que são redundantes. Ou, a solução ARR (Application Request Routing) da Microsoft também é uma ótima opção.

Para o SQL Server, as opções internas de cluster, espelhamento ou envio de logs geralmente se encaixam na conta, além de produtos como o DoubleTake fazerem um ótimo trabalho ao atender a essa necessidade.

No nível do aplicativo, você precisará garantir que nada dependa de um único nó. O estado da sessão é a dependência mais comum. Se for usado, ele precisa ser transferido para uma solução redundante. SQLServer Session State, ScaleOutSoftware e agora AppFabric são todas as opções a considerar.

A redundância real precisa ser geo-redundante nos datacenters, que precisam estar longe o suficiente para que não sejam afetados por nenhum grande desastre natural.

E, nenhuma tecnologia é suficiente sem muitos testes e ótimos processos e procedimentos para saber como lidar com situações inesperadas da melhor maneira possível, e para testar as várias partes redundantes do sistema em intervalos regulares.