INFRAESTRUTURA PRIVADA OFFSHORE
Web e onionAplicado · 4 min de leitura

Escolha um modelo operacional de alojamento antes de escolher uma nuvem

Compare alojamento partilhado, um VPS, hardware dedicado e grandes plataformas de nuvem através da responsabilidade, recuperação, dependências e do orçamento operacional completo.

Por SwissOctet Editorial
A RESPOSTA DIRETA

Compare os modelos de alojamento através das responsabilidades operacionais que atribuem e da arquitetura que permitem. A escala da nuvem, uma máquina virtual e o hardware dedicado descrevem aspetos diferentes de um sistema; nenhum deles, por si só, prova privacidade, custo ou comportamento de recuperação.

01

Comece pelo trabalho que precisa que alguém assuma

Uma decisão de alojamento atribui trabalho operacional, bem como recursos computacionais. Um projeto precisa de uma conta que execute um site convencional; outro precisa de controlo sobre os pacotes do sistema operativo e os processos em segundo plano. Um terceiro precisa de uma plataforma de base de dados cuja manutenção seja assegurada ao abrigo de um contrato de serviço específico. Enumere primeiro essas responsabilidades, juntamente com as pessoas disponíveis para as manter.

O alojamento partilhado expõe tipicamente um ambiente ao nível da conta. Um VPS expõe um sistema operativo convidado, enquanto o hardware dedicado move o limite da máquina para um servidor físico. Gerido é uma questão separada: um rótulo de produto não lhe diz quem aplica as correções, restaura os dados ou investiga um incidente. Peça o âmbito da gestão e um procedimento de recuperação em vez de o tratar como uma funcionalidade universal.

02

Compreenda o que a nuvem acrescenta à comparação

O NIST descreve a computação em nuvem através de características como o acesso a pedido, a partilha de recursos, a elasticidade e o serviço medido. Uma máquina virtual pode ser um componente de uma plataforma de nuvem, pelo que VPS e nuvem não são tecnologias mutuamente exclusivas. A comparação útil é entre os serviços concretos oferecidos: uma máquina virtual fixa, uma frota elástica ou uma aplicação construída em torno de serviços geridos.

Hyperscaler é um termo da indústria para um fornecedor que opera infraestrutura e plataformas de serviços a uma escala muito grande. Essa escala pode oferecer uma ampla variedade de ferramentas de implementação e escolhas geográficas; não lhe diz se uma arquitetura específica satisfaz as suas necessidades. Avalie a região, as dependências de serviço, o modelo de identidade e o contrato de cada componente. Um fornecedor mais pequeno e uma grande plataforma exigem ambos uma descrição clara de para onde vão os dados.

Modelo operacionalControlo disponível para o projetoQuestão antes de escolher
Conta de alojamento partilhadoDefinições do site dentro do âmbito da contaO ambiente de execução é adequado à aplicação?
Máquina virtualSistema operativo convidado e serviços instaladosQuem mantém e restaura o convidado?
Máquina dedicadaUm limite de servidor físicoA carga de trabalho justifica este limite?
Serviço de nuvem geridoA API do serviço e as definições suportadasO que continua a ser responsabilidade do cliente?
03

Escolha uma arquitetura que consiga recuperar

Uma única máquina pode ser um ponto de partida sensato para uma pequena aplicação quando os seus requisitos de recuperação permitem a restauração ou uma janela de manutenção planeada. Adicionar um segundo nó de aplicação só altera o design se o encaminhamento de tráfego, as sessões e os dados persistentes funcionarem corretamente em ambos. Dois servidores a executar o mesmo plano de recuperação incompleto continuam a ser um plano de recuperação incompleto.

O armazenamento distribuído ilustra esta distinção. Software como o Ceph distribui o trabalho de armazenamento por um cluster e oferece interfaces de objeto, bloco e ficheiro. A replicação ou a codificação por eliminação podem ajudar a tolerar falhas específicas de hardware, mas o cluster também precisa de capacidade para recuperação e reequilíbrio. Uma cópia ativa distribuída não substitui uma cópia de segurança independente. Decida como as escritas se comportam durante uma partição de rede e teste os casos de falha relevantes para a implementação escolhida.

04

Compare o orçamento operacional completo

Escreva o orçamento como uma carga de trabalho: tráfego normal, um intervalo de pico, dados armazenados, retenção de cópias de segurança e transferência necessária para a recuperação. Inclua software pago, APIs externas, tempo de administração e o custo de voltar a mover os dados. Um valor mensal inicial e uma estimativa baseada na utilização respondem a perguntas diferentes. Compare-os no mesmo período e mantenha as premissas junto do resultado.

Para uma grande plataforma de nuvem, identifique todos os serviços necessários para manter a aplicação em funcionamento. Para um VPS, inclua o trabalho que os serviços geridos absorveriam de outra forma. Nenhuma das abordagens é automaticamente mais barata. Comece com uma pequena implementação representativa ou um orçamento documentado e, em seguida, reveja a fatura real em comparação com o modelo. Reserve margem para o tráfego de recuperação e a capacidade de migração temporária, em vez de orçamentar apenas o estado estacionário.

05

Trate a privacidade como um mapa de dependências

A região da máquina é uma entrada num mapa mais amplo. A autenticação, a monitorização, as ferramentas de suporte, as cópias de segurança e as APIs de modelos podem funcionar através de serviços separados. Registe o que cada um recebe, quem pode aceder-lhe e durante quanto tempo é retido. O modelo de responsabilidade partilhada da AWS é um exemplo de um fornecedor que separa explicitamente as suas funções de infraestrutura das funções do cliente; o âmbito muda com o serviço.

Use essa distinção ao comparar fornecedores, sem importar as obrigações de um fornecedor para outro contrato. Uma configuração SwissOctet descreve um local de alojamento e os recursos listados. Não estabelece a localização das integrações que adicionar mais tarde. Minimize os dados que cada dependência recebe, proteja a administração e verifique os destinos de cópia de segurança antes de fazer uma afirmação sobre o percurso dos dados da sua própria aplicação.

06

Use o caminho de migração como parte da decisão

Verifique como pode exportar os dados da aplicação, a configuração e as identidades. Uma aplicação convencional numa máquina virtual pode ser simples de mover, enquanto uma base de dados ou um sistema de eventos específico de um serviço pode exigir uma adaptação. A portabilidade também depende do conhecimento operacional: uma cópia de segurança que ninguém sabe restaurar é um plano de saída fraco, mesmo que o seu formato seja aberto.

Para uma primeira lista restrita de SwissOctet, compare o Canvas quando um ambiente web ao nível da conta for adequado, o Vector para controlo do sistema operativo convidado e as gamas Metal quando o limite físico for importante. As opções orientadas para o armazenamento suportam uma questão de capacidade diferente e não devem ser descritas como um cluster distribuído gerido. Mantenha a arquitetura suficientemente pequena para operar e adicione complexidade de plataforma quando esta responder a um requisito testado, e não a uma escala futura imaginada.

TRANSFORME ISTO EM AÇÃO

A sua lista de verificação prática.

  • Atribua a propriedade da administração e da recuperação.
  • Distinga uma VM da plataforma de nuvem mais ampla.
  • Orçamente dependências, transferência e manutenção.
  • Teste um limite de falha antes de adicionar nós.
  • Registe uma exportação de dados e um caminho de migração exequíveis.
PERGUNTAS FREQUENTES

Os detalhes que importam.

Um VPS pode fazer parte de uma plataforma de nuvem?+

Sim. Uma máquina virtual pode ser um serviço de nuvem. Compare o recurso, o modelo de escalabilidade e o modelo de gestão reais, em vez de assumir que os nomes descrevem tecnologias exclusivas.

O armazenamento distribuído substitui as cópias de segurança?+

Não. A redundância ativa aborda falhas selecionadas de componentes. Uma cópia de segurança independente e um teste de restauração abordam outras falhas, como a eliminação e dados de aplicação danificados.

Uma grande nuvem é sempre uma má escolha de privacidade?+

Não. Avalie os serviços específicos, os fluxos de dados e os controlos contratuais. A dimensão do fornecedor, por si só, não estabelece a adequação da arquitetura.

REFERÊNCIAS PRIMÁRIAS

Vá à fonte.

Estas referências sustentam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema de produção.

  1. NIST SP 800-145: A Definição de Computação em Nuvem nvlpubs.nist.gov
  2. AWS: Modelo de Responsabilidade Partilhada aws.amazon.com
  3. Ceph: Arquitetura de Armazenamento docs.ceph.com
  4. Ceph: Codificação por eliminação docs.ceph.com

Orientação editorial da SwissOctet. Os exemplos são ilustrativos. As especificações de serviço, as opções disponíveis e as condições contratuais devem ser verificadas separadamente.

LIGUE O CONHECIMENTO

Infraestrutura relacionada.

MANTENHA O FIO

As suas próximas notas de campo.

Explore todos os guias