Em vez de montar um \u00fanico servidor com componentes redundantes, existe tamb\u00e9m a op\u00e7\u00e3o de usar um cluster de alta disponibilidade (chamados de “high-availability clusters” ou “failover clusters”), onde s\u00e3o usados dois servidores completos, onde a \u00fanica fun\u00e7\u00e3o do segundo servidor \u00e9 assumir a posi\u00e7\u00e3o do primeiro em caso de falhas (modo chamado de ativo\/passivo), diferente de um cluster com balanceamento de carga, onde os servidores dividem as requisi\u00e7\u00f5es (ativo\/ativo).<\/p>\n
Existem diversas solu\u00e7\u00f5es para clusters de alta disponibilidade. Entre as solu\u00e7\u00f5es abertas, uma das mais usadas \u00e9 o projeto Linux-HA (High-Availability Linux, dispon\u00edvel no http:\/\/www.linux-ha.org), que desenvolve o heartbeat, um daemon respons\u00e1vel por monitorar o status dos servidores do cluster e permitir que o segundo servidor assuma as fun\u00e7\u00f5es do primeiro em caso de pane.<\/p>\n
Cada um dos servidores possui pelo menos duas placas de rede, o que permite que eles sejam simultaneamente ligados \u00e0 rede e ligados entre si atrav\u00e9s de um cabo cross-over ou de um switch dedicado. A conex\u00e3o interna \u00e9 usada pelo heartbeat para as fun\u00e7\u00f5es de monitoramento e sincronismo dos processos, de forma que o segundo servidor possa assumir imediatamente a fun\u00e7\u00e3o do primeiro quando necess\u00e1rio, assumindo o endere\u00e7o IP anteriormente usado por ele.<\/p>\n
\u00c9 comum tamb\u00e9m o uso de uma terceira interface de rede em cada servidor (ligada a um switch separado), destinada a oferecer uma conex\u00e3o de backup com a rede. Isso permite eliminar mais um poss\u00edvel ponto de falha, afinal, de nada adianta ter servidores redundantes se o switch que os liga \u00e0 rede parar de funcionar. \ud83d\ude42<\/p>\n
Em geral, o heartbeat \u00e9 usado em conjunto com o Drbd (http:\/\/www.drbd.org), que assume a fun\u00e7\u00e3o de manter os HDs dos dois servidores sincronizados, como uma esp\u00e9cie de RAID 1 via rede. Ao usar o Drbd, o HD do segundo servidor assume o papel de unidade secund\u00e1ria e \u00e9 atualizado em rela\u00e7\u00e3o ao do primeiro em tempo real. Quando o primeiro servidor p\u00e1ra, a unidade de armazenamento do segundo servidor passa a ser usada como unidade prim\u00e1ria. Quando o servidor principal retorna, o HD \u00e9 sincronizado em rela\u00e7\u00e3o ao secund\u00e1rio e s\u00f3 ent\u00e3o ele reassume suas fun\u00e7\u00f5es.<\/p>\n
Outra op\u00e7\u00e3o \u00e9 utilizar uma SAN (veja a seguir) para que os dois servidores compartilhem a mesma unidade de armazenamento. Nesse caso, n\u00e3o \u00e9 necess\u00e1rio manter o sincronismo, j\u00e1 que os dados s\u00e3o armazenados em uma unidade comum aos dois servidores.<\/p>\n
Como pode ver, adicionar componentes redundantes, sejam fontes, HDs ou servidores adicionais aumentam consideravelmente os custos. A principal quest\u00e3o \u00e9 avaliar se o preju\u00edzo de ter o servidor fora do ar por algumas horas ou dias durante as manuten\u00e7\u00f5es, acidentes e imprevistos em geral \u00e9 maior ou menor do que o investimento necess\u00e1rio.<\/p>\n
Um pequeno servidor de rede local, que atende a meia d\u00fazia de usu\u00e1rios em um pequeno escrit\u00f3rio dificilmente precisaria de redund\u00e2ncia, mas um servidor de miss\u00e3o-cr\u00edtica (como no caso de um banco) com certeza precisa. Cada n\u00edvel de redund\u00e2ncia adiciona um certo valor ao custo dos servidores, mas reduz em certa propor\u00e7\u00e3o o tempo de downtime.<\/p>\n
A disponibilidade do servidor \u00e9 genericamente medida em “noves”. Um nove indica uma disponibilidade de 90%, ou seja, uma situa\u00e7\u00e3o em que o servidor fica fora do ar at\u00e9 10% do tempo (imagine o caso de uma m\u00e1quina inst\u00e1vel, que precisa ser freq\u00fcentemente reiniciada, por exemplo), o que n\u00e3o \u00e9 admiss\u00edvel na maioria das situa\u00e7\u00f5es.<\/p>\n
Com dois noves temos um servidor que fica dispon\u00edvel 99%, o que seria uma boa marca para um servidor “comum”, sem recursos de redund\u00e2ncia. Por outro lado, uma disponibilidade de 99% significa que o servidor pode ficar fora do ar por at\u00e9 7 horas e 18 minutos por m\u00eas (incluindo todas as manuten\u00e7\u00f5es, quedas de energia, opera\u00e7\u00f5es de backup que tornem necess\u00e1rio parar os servi\u00e7os e assim por diante), o que \u00e9 toler\u00e1vel no caso de uma rede local, ou no caso de um servidor que hospeda um site fora da \u00e1rea de com\u00e9rcio eletr\u00f4nico, mas ainda n\u00e3o \u00e9 adequado para opera\u00e7\u00f5es de miss\u00e3o cr\u00edtica.<\/p>\n
Para adicionar mais um nove, atingindo 99.9% de disponibilidade (o famoso “three nines”), n\u00e3o \u00e9 poss\u00edvel mais contar apenas com a sorte. \u00c9 necess\u00e1rio come\u00e7ar a pensar nos poss\u00edveis pontos de falha e come\u00e7ar a adicionar recursos de redund\u00e2ncia. Entram em cena as fontes redundantes, o uso de uma controladora RAID com suporte a hot-swap, uso de um nobreak com boa autonomia para todo o equipamento de rede, de forma que o servidor continue dispon\u00edvel mesmo durante as quedas de luz, e assim por diante. Afinal, 99.9% de disponibilidade significa que o servidor n\u00e3o fica fora do ar por mais de 43 minutos por m\u00eas.<\/p>\n
No caso de servidores de miss\u00e3o cr\u00edtica, qualquer interrup\u00e7\u00e3o no servi\u00e7o pode representar um grande preju\u00edzo, como no caso de institui\u00e7\u00f5es financeiras e grandes sites de com\u00e9rcio eletr\u00f4nico. Passa ent\u00e3o a fazer sentido investir no uso de um cluster de alta disponibilidade e em links redundantes, de forma a tentar atingir 99.99% de disponibilidade. Esta marca \u00e9 dif\u00edcil de atingir, pois significa que o servidor n\u00e3o deve ficar mais do que 4 minutos e meio (em m\u00e9dia) fora do ar por m\u00eas, incluindo a\u00ed tudo o que possa dar errado.<\/p>\n
Como sempre, n\u00e3o existe uma f\u00f3rmula m\u00e1gica para calcular o ponto ideal (\u00e9 justamente por isso que existem consultores e analistas), mas \u00e9 sempre prudente ter pelo menos um n\u00edvel m\u00ednimo de redund\u00e2ncia, nem que seja apenas um backup atualizado, que permita restaurar o servidor (usando outra m\u00e1quina) caso alguma trag\u00e9dia aconte\u00e7a.<\/p>\n","protected":false},"excerpt":{"rendered":"
Em vez de montar um \u00fanico servidor com componentes redundantes, existe tamb\u00e9m a op\u00e7\u00e3o de usar um cluster de alta disponibilidade (chamados de “high-availability clusters” ou “failover clusters”), onde s\u00e3o usados dois servidores completos, onde a \u00fanica fun\u00e7\u00e3o do segundo servidor \u00e9 assumir a posi\u00e7\u00e3o do primeiro em caso de falhas (modo chamado de ativo\/passivo), […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[33,31,32,14],"class_list":["post-80","post","type-post","status-publish","format-standard","hentry","category-viazap","tag-clone","tag-cluster","tag-disponibilidade","tag-linux"],"_links":{"self":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/80","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=80"}],"version-history":[{"count":1,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/80\/revisions"}],"predecessor-version":[{"id":81,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/80\/revisions\/81"}],"wp:attachment":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=80"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=80"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=80"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}