O hardware HA deve estar em gabinetes separados?

Question

Eu quero hospedar (co-localizado) um serviço em um Pier1, Q9 ou alguma instalação de hospedagem semelhante.
É uma boa prática colocar meu hardware de failover em gabinetes separados e, na sua experiência, o provedor de hospedagem permitirá isso?

Minha preocupação é que, se algo acontecer, por exemplo, pegar fogo no gabinete ou um inquilino descontente em rack colocar sua coca nos servidores, ambas as minhas pilhas HA estarão comprometidas.

Na sua experiência, se eu colocá-los em gabinetes separados, eles podem estar na mesma sub-rede, ou é contra a política de hospedagem para mim executar um cabo de um gabinete e outro?

Ou será que esse tipo de evento nunca ocorre e eu deveria parar de me preocupar?

Edit: É um aplicativo da web stateless de alto valor comercial, no qual segundos de tempo de inatividade seriam muito prejudiciais.

    

Answer 1

Depende dos requisitos de alta disponibilidade do seu serviço.

Se o serviço não é tão importante para os negócios, provavelmente não faz sentido separar os nós do cluster entre os gabinetes, especialmente se a infraestrutura ao redor, como rede básica, balanceadores de carga etc., também estiver dividida.

Em serviços de alto valor comercial, separar os nós no cluster de failover para separar as câmaras de incêndio é uma prática comum e eu recomendo fazê-lo se a empresa considerar que vale a pena e está disposta a pagar o preço.

Sim, o provedor de hospedagem permitirá que você faça isso, a menos que seja um dos menores e não tenha vários gabinetes.

Normalmente você não executa seus próprios cabos entre gabinetes. O provedor oferece a interconexão entre os gabinetes como um serviço e você tem sua rede principal conectada com ele ou o provedor também pode oferecer a rede como um serviço.

Os nós no cluster podem usar a mesma VLAN, que ainda permanece como um SPOF além da tecnologia de clustering em si e provavelmente também o armazenamento comum. Para evitar que os serviços falhassem nesses componentes, você precisaria criar um sistema de recuperação de desastre, que é comumente localizado geograficamente longe o suficiente e onde o serviço é espelhado de forma assíncrona.

    

Answer 2

Falha de energia em rack único é mais comum do que a maioria das outras preocupações listadas por você: uma única faixa de PDU estourando ou um circuito ficando sobrecarregado ... Eu tive isso acontecendo um punhado de vezes, mas nenhuma das outras problemas que você listou.

Idealmente, sua solução 'HA' usa dois datacenters diferentes. (por exemplo, duas zonas em uma região da AWS)

    

Answer 3

Não necessariamente. Depende de que tipos de situações você deseja realisticamente proteger.

Eu tive vários ambientes em que a estratégia de alta disponibilidade era construir pilhas de aplicativos paralelas em vários gabinetes. Isso significava todos os níveis do aplicativo / serviço; switching, firewalls, etc. estavam presentes em dois gabinetes, de modo que poderíamos perder um rack inteiro (ou qualquer componente dentro dele) sem afetar a disponibilidade do aplicativo.

Você não especifica o escopo ou a natureza do seu aplicativo. Mais detalhes ajudariam lá. Mas se você está falando de algo pequeno como um único servidor, isso não é necessário. A separação geográfica, o failover de DNS e a certeza de que os servidores individuais têm redundâncias internas (fontes de alimentação duplas, ventiladores redundantes, RAID) serão um bom começo.

O cabeamento em execução entre gabinetes (conexões cruzadas) dentro de uma instalação não é incomum. Normalmente, é o resultado de não conseguir obter espaço contíguo. Mas eu não me preocuparia com um técnico derramando uma bebida líquida no seu rack ou fogo ... Embora, incêndios de componentes podem ocorrer ... mas eu tive uma pilha de infraestrutura de failover inteira para evitar tempo de inatividade.

    

Answer 4

Depende. Seus medos são razoáveis, embora os problemas que você descreve sejam raros.

Eu diria que certamente é melhor ter a unidade redundante em outro rack, se não em outro prédio / cidade. Não tenho certeza se gastaria extra apenas para ter o servidor redundante em um rack adjacente. Mas, se o custo é o mesmo, não pode doer.

Os provedores de hospedagem não permitem que você execute seu próprio cabo entre os gabinetes. Mas, eles colocarão suas duas portas de rede (uma em cada gabinete) na mesma VLAN, para que você possa usar a mesma sub-rede, se isso for importante para você.

Só você pode decidir o que uma falha vale para você. Depois de descobrir isso, você saberá se vale a pena se preocupar ou não.

    

Answer 5

O risco de incêndio ou sabotagem que você mencionou, ou outros problemas ambientais semelhantes, provavelmente não será adequadamente mitigado colocando sua tecnologia em racks próximos o suficiente para tornar viável a execução de um cabo entre eles. Considere as tempestades do ano passado na área de NYC: datacentros inteiros estavam fora da grade.

Eu sugiro que não vale a pena se preocupar muito com HA, a menos que você tenha uma separação adequada entre os membros do cluster, ou pelo menos se você está muito claro que isso está sendo implementado para lidar com a execução normal de erros (por exemplo, servidores quebrando) ao invés de algo mais exótico.

    

Answer 6

O ponto-chave da resiliência é que ela pode ser tão profunda ou superficial quanto você deseja (ou tem fundos para). O equivalente técnico disso é que você pode unicast ou multicast tanto quanto você quiser (ou você tem fundos para).

Se sua empresa tiver uma exigência de resiliência, a empresa identificará até que ponto essa resiliência deve ser fornecida. Se você tem uma rede que é necessária 5 minutos todos os dias, qual é a resiliência? Se a sua rede é hospitalar e relevante 24x7x365, você tem um objetivo completamente diferente.

Eu trabalhei em um ambiente onde ex-funcionários da Cisco tentaram ditar os requisitos e o que eu devo fazer e ainda assim eles entenderam mal a infraestrutura e não o que a empresa / cliente exige.

Se você precisar de total resiliência, a empresa atenderá ao custo. Se você não, não se incomode ..

É realmente a decisão de outra pessoa.