por Equipe | jan 4, 2021 | Artigos
A infraestrutura hiperconvergente (HCI) oferece a promessa de infraestrutura de TI simplificada, com a capacidade de crescer facilmente. Ele faz isso combinando computação e armazenamento em uma única plataforma ou nó que pode ser integrado em clusters de forma escalável.
Os compradores podem escolher nós hiperconvergentes prontos para executar diretamente dos fornecedores, como um pacote com hardware e software, ou construir seus próprios usando hardware comum e software HCI.
Com opções baseadas em software e hardware no mercado, HCI pode ser uma opção para uma ampla variedade de casos de uso, incluindo aplicativos que não justificariam um novo hardware.
Cinco casos de uso aplicados a Hiperconvergência
1. Virtualização
Servidores virtuais e desktops virtuais são casos de uso importantes para infraestrutura hiperconvergente. Cada vez mais, os fornecedores hiperconvergentes de software estão se concentrando neste espaço.
O HCI oferece integração mais estreita e gerenciamento mais fácil do que um sistema construído em torno de componentes separados.
A virtualização também é um caso de uso para HCI baseada em hardware, especialmente para aplicativos sensíveis ao desempenho e onde há uma oportunidade de implantar novo hardware. Mas a hiperconvergência baseada em hardware também tem uma função na virtualização de desktop (VDI).
O VDI pode se beneficiar da estreita conexão entre computação, armazenamento e rede, mas especialmente da facilidade de implantação e gerenciamento. Esse é particularmente o caso em implantações de novas compilações.
Uma infraestrutura nova e dedicada é mais fácil de gerenciar do que adaptar o HCI na infraestrutura de servidor existente e nos computadores desktop que ela substitui.
2. PMEs e escritórios remotos
A hiperconvergência oferece uma maneira eficaz para as organizações melhorarem o gerenciamento de TI remota e de filiais.
Hardware dedicado e integrado pode parecer uma maneira cara de equipar escritórios remotos. Mas os fornecedores percebem o mercado potencial para locais menores e remotos, onde a facilidade de gerenciamento é importante.
A Hiperconvergência se adapta a ambientes sem uma equipe de TI local. A abordagem de fornecedor único elimina a necessidade de lidar com vários tipos de hardware e o HCI foi desenvolvido para gerenciamento remoto. Os fornecedores também podem pré-configurar os sistemas, para que a equipe de TI tenha menos versões do ambiente para oferecer suporte.
Um serviço de suporte de TI pode usar as ferramentas de implantação e administração da HCI para administrar remotamente a infraestrutura de uma empresa menor. Isso se aplica igualmente a pequenas e médias empresas (PMEs) que executam seus próprios datacenters onde a hiperconvergência permite o gerenciamento de todos os componentes a partir de uma interface.
As PMEs também são menos sensíveis a alguns dos problemas de desempenho que podem afetar o hardware hiperconvergente, trocando isso pela facilidade de uso. E a empresa, ou seu contratante de TI, pode integrar sistemas hiperconvergentes locais com recursos baseados em nuvem, para backup, recuperação e arquivamento.
3. Containers e Kubernetes
Os contêineres são um ajuste natural para HCI, especialmente no datacenter. Como os contêineres não precisam de um hipervisor, eles podem trabalhar diretamente com o sistema operacional e hardware subjacentes.
Mudar para HCI simplifica ainda mais a infraestrutura. O orquestrador de contêineres mais comum, o Kubernetes, é executado no Linux. Cada aplicativo é executado em seu próprio contêiner e compartilha os recursos do servidor host.
Muitos dos motivos pelos quais o HCI funciona bem para virtualização se aplicam igualmente a contêineres. Os contêineres simplificam a virtualização e o HCI simplifica o hardware.
4. Analytics, aprendizado de máquina e IA
Para análises, aprendizado de máquina e inteligência artificial (AI), os motivadores para HCI são a implantação rápida e a capacidade de escalar adicionando nós.
O acoplamento estreito das partes componentes de TI melhora o desempenho e a confiabilidade. E a abordagem de nó do software hiperconvergente funciona bem para aplicativos como aprendizado de máquina e IA, onde o armazenamento de dados e os recursos de computação geralmente precisam crescer juntos para evitar gargalos.
Poucos sistemas de aprendizado de máquina ou análise avançada são estáticos. Normalmente, eles são projetados com o crescimento em mente, com uma alimentação constante de novos dados.
Como o HCI foi projetado para escalar, ele deve ser capaz de lidar com volumes crescentes de dados, bem como com desenvolvimentos mais recentes – como análise de streaming – que exigem muita computação e rede.
Enquanto isso, tecnologias como Hadoop são projetadas para ambientes distribuídos e se prestam a nós em vez de silos de armazenamento e recursos de computação.
5. Backup e recuperação de desastres
De certa forma, a Hiperconvergência para backup é o caso de uso mais simples de todos. Basta instalar um segundo sistema hiperconvergente para redundância e duplicação de dados.
A Hiperconvergência é flexível o suficiente para oferecer suporte a sistemas de backup e recuperação de desastres no local, em um local secundário ou de failover, ou na nuvem.
HCI não é, entretanto, um backup focado em armazenamento ou sistema de arquivamento. Se o requisito for simplesmente copiar dados, outras plataformas serão mais econômicas.
Uma das vantagens da HCI é sua abordagem de “sistema integrado”. Com computação, armazenamento e rede em um só lugar e suporte integrado para virtualização e contêineres, a hiperconvergência é uma das maneiras mais rápidas de colocar um negócio online novamente.
Então, por que HCI?
É uma arquitetura incrivelmente flexível, especialmente agora que as empresas podem implantá-la integrada por meio de hardware e software, para reutilizar ativos existentes e integrá-la à nuvem.
À medida que os fornecedores desenvolvem seus produtos e melhoram a capacidade de executar cargas de trabalho convencionais e de contêineres junto com a virtualização convencional, é provável que se torne ainda mais popular e estratégica para as empresas.
Sobre a OST
Desde 1995 no mercado, a OST atende com excelência fornecendo soluções de infraestrutura, auxiliando organizações públicas e privadas a garantirem a continuidade de seus negócios.
Somos especializados em otimizar e atender a necessidade do seu negócio. A OST garante a continuidade de suas operações, fornecendo soluções avançadas de infraestrutura para ambientes de missão crítica com inovação, excelência e qualidade no serviço.
por Equipe | ago 27, 2020 | Artigos
A computação em nuvem está facilitando muito alguns aspectos da recuperação de desastres, especialmente com o crescimento dos serviços de backup online. Mas a nuvem pode adicionar complexidade às operações de TI, especialmente em ambientes híbridos.
Além disso, existe a capacidade das linhas de negócios de aumentar seus próprios recursos na nuvem ou de comprar aplicativos de software como serviço (SaaS), o que significa que a TI pode não ter mais uma imagem completa da infraestrutura de TI da organização. E o plano inclui o que fazer se um serviço em nuvem cair?
A recuperação de desastres (DR) é a capacidade de retornar às operações “normais” após uma falha de TI, desastre natural ou outro evento inesperado e é uma função fundamental da TI.
Afinal, o departamento de TI é responsável pela manutenção dos principais sistemas de negócios e pela proteção de seus dados, por fornecer desktops ou outros computadores pessoais, acesso a nuvem, redes e, na maioria das vezes, comunicações de voz.
Mas o planejamento de recuperação de desastres em uma ambiente de nuvem híbrida é um desafio e uma responsabilidade de toda a empresa. As organizações dependem cada vez mais de seus dados, e a TI está se tornando cada vez mais hábil em fornecer acesso a esses dados em qualquer lugar do mundo.
Mas dada a crescente complexidade das operações de negócios e dos sistemas de TI. existem muitas armadilhas para as empresas que não estão preparadas.
Armadilha de DR 1: Falha no planejamento
A maior falha é deixar de planejar a recuperação de desastres.
Um plano de DR não precisa ser complexo. No caso de uma pequena empresa ou filial, pode incluir pouco mais do que backups regulares em discos armazenados externamente ou, cada vez mais, na nuvem, e um plano de como acessar os dados e restaurar aplicativos se o pior acontecer.
Para organizações maiores, um plano entrará em muito mais detalhes sobre quais aplicativos são protegidos, como eles serão recuperados e arranjos para espaços de trabalho alternativos para a equipe.
Um plano deve indicar em que ordem as várias plataformas devem ser recuperadas. Às vezes, isso fica óbvio pelos requisitos do aplicativo ou serviço, mas quando uma grande recuperação do site é necessária, a política interna também pode entrar em jogo.
Outros problemas ocorrem quando as organizações têm um plano de DR, mas é muito limitado em escopo. Aqui, a TI e o conselho podem ser enganados por uma falsa sensação de segurança. Nesses casos, existe um plano de DR, mas ele falha em cobrir todos os aplicativos e, principalmente, suas interdependências.
O plano também deve definir o objetivo do ponto de recuperação (RPO) e o objetivo do tempo de recuperação (RTO) quanto tempo a organização precisa voltar para obter um conjunto limpo e estável de aplicativos e dados e com que rapidez isso deve acontecer.
Armadilha 2 de DR: falha no teste
A próxima armadilha, e talvez a maior, é não conseguir testar. Uma estatística frequentemente citada é que 23% das organizações nunca testam seus planos de DR, com outros 29% testando apenas uma vez por ano.
A adequação de um teste anual dependerá muito do tamanho e da natureza do negócio. Mas um plano que nunca é testado está realmente a um passo de não ter nenhum plano.
O outro grande problema diz respeito aos testes de processos de recuperação de desastres. Isso é essencial porque até que você teste o DR, você realmente não pode ter certeza de que funcionará, ou se todos os sistemas que deveriam ser protegidos o foram.
Garantir um regime de teste robusto requer forte liderança do CIO. O teste de DR eficaz pode ser disruptivo e caro. Mas deixar de se recuperar de um desastre será ainda mais caro.
Se a organização testar o plano, os CIOs precisam garantir que todas as lições aprendidas – e haverá lições aprendidas – sejam usadas para atualizar o plano. O plano atualizado precisa ser testado e o ciclo repetido.
Armadilha 3 de DR: falha em proteger backups
Malware, e especialmente ransomware , é um dos motivos pelos quais o DR voltou à pauta nos últimos anos.
Proteger sistemas contra ransomware em particular significa criar uma lacuna entre os sistemas de produção e as cópias de backup ou usar tecnologias de armazenamento imutáveis, até porque os invasores aprenderam a direcionar os backups de dados primeiro. Algumas organizações voltaram à fita como uma forma de custo relativamente baixo de mover dados para um local externo.
Infelizmente para as equipes de DR, isso nem sempre é fácil. Os planos de continuidade dos negócios e os objetivos de menor tempo de recuperação contam com a proteção contínua de dados.
Armadilha 4 de DR: negligenciando fatores humanos
Os departamentos de TI, naturalmente, concentram seu planejamento de DR em sistemas e dados. Mas os planos eficazes também precisam cobrir onde e como as pessoas trabalharão se o local principal da empresa for comprometido.
Pode ser que os funcionários possam trabalhar em casa inicialmente, mas por quanto tempo eles podem sustentar isso?
Alguns funcionários precisam de computadores desktop ou mais largura de banda do que as conexões domésticas ou móveis podem fornecer? E quanto aos espaços de encontro e ao bem-estar físico e mental da equipe? Manter o moral no caso de um desastre costuma ser tão importante quanto os aspectos técnicos do plano de recuperação.
Armadilha 5 de DR: problemas de comando, controle e comunicação
Em uma situação de recuperação de desastre, linhas de comunicação claras e uma ideia clara de quem está no controle são vitais.
As organizações também precisam decidir quem pode invocar o plano de DR e garantir que toda a equipe principal possa continuar a se comunicar durante uma interrupção. Um teste de DR robusto geralmente expõe quaisquer falhas no comando e controle, e as comunicações de crise devem fazer parte do plano para empresas maiores.
Mas também há uma necessidade de comunicação contínua em torno de DR e continuidade de negócios. Comunicações claras ajudarão a gerenciar as expectativas sobre quais dados e sistemas podem ser recuperados, em que ordem e com que rapidez.
A pior coisa que uma empresa pode fazer é investir em um plano de DR e, em seguida, deixá-lo na prateleira
A recuperação de desastres ou exercícios de continuidade de negócios podem ser perturbadores, mas planos eficazes de DR precisam ser testados, revisados e atualizados. Quase a pior coisa que uma empresa pode fazer é investir em um plano de DR e, em seguida, deixá-lo na prateleira.
É apenas testando que a empresa saberá se o plano funciona e se é suficientemente resiliente para funcionar sob pressão. Simular e testar os sistemas de comunicação é a melhor maneira de expor qualquer fraqueza.
As equipes podem, então, alimentar os insights obtidos na fase de teste de volta à avaliação de risco e à análise de impacto nos negócios, ajustando o plano à medida que avançam.
Para saber mais sobre como a nuvem híbrida pode contribuir para o sucesso do seu negócio, entre em contato com os especialistas da OST.
Sobre a OST
Desde 1995 no mercado, a OST atende com excelência fornecendo soluções de infraestrutura, auxiliando organizações públicas e privadas a garantirem a continuidade de seus negócios.
Somos especializados em otimizar e atender a necessidade do seu negócio. A OST garante a continuidade de suas operações, fornecendo soluções avançadas de infraestrutura para ambientes de missão crítica com inovação, excelência e qualidade no serviço.
