Micro serviços e cloud computing

Micro serviços em estrutura cloud

Micro serviços em estrutura cloud

Para a edição de hoje gostaria de mostrar um pouco da arquitetura de micro serviços utilizando uma estrutura em cloud computing. Assim, mostrarei um pouco sobre esta estrutura e como podemos tirar ganhos em diversos projetos.

Os micro serviços

Antes de mais nada é preciso entender alguns pontos chaves do conceito de micro serviços. Imagine um cenário onde você possui uma aplicação que deve suportar uma gama diferente de usuários que utilizam browsers desktop, mobile e alguns ainda utilizam sua aplicação através de um app nativo. Complicando um pouco mais esta aplicação possui uma API aberta para integração do seu sistema com outros sistemas (Algo muito comum por exemplo, no facebook, google, twitter e etc).

Concordam que está aplicação, sem nem mesmo falarmos das funcionalidades, teria um corpo complexo e demasiadas responsabilidades para conseguir gerenciar? Mas porque deixar isto tudo nas mãos de apenas um sistema?!

Desde que comecei a aprender um pouco sobre orientações a objetos (há uns 8-9 anos atrás) comecei a relacionar sistemas como o próprio sistema orgânico. Ou seja, cada coisa deve ter sua responsabilidade específica e simples. Assim, ela pode exercer melhor e com mais desempenho sua determinada função.

Quando comecei a conhecer a arquitetura de micro serviços consegui enxergar perfeitamente esta organicidade no macro de um projeto. Poxa, porque um projeto com tantos requisitos e tantas responsabilidades precisam sem emaranhar em apenas uma estrutura monolítica gigantesca. Consegue imaginar a complexidade de códigos, classes que vão se desembrulhando para responder às regras exemplificadas acima?!

O conceito de micro serviços traz uma proposta simplicadora. Vamos reduzir este grande sistema em um sistema com N serviços auxiliares e específicos que serão responsáveis por cada regra. Um serviço responsável pelo tratamento de clientes, um pela comunicação da API que por sua vez trabalhará com um serviço que montará a interface para o usuário e assim por diante… Posso trazer mil analogias com o que vemos no mundo real em grandes organizações, orquestras, times e etc. Os micro serviços trabalham de forma grupal para trazer um resultado unificado.

Resultado disto tudo

  • Micro serviços devem ser considerados como sistemas relativamente pequenos assim temos maior simplicidade em entender seu código
  • Maior produtividade no desenvolvimento, desde o processamento de menos arquivos pela IDE de desenvolvimento até menor curva de aprendizado do serviço.
  • Facilidade ao escalar seu desenvolvimento. Já que estes serviços trabalham em paralelo é possível que diferentes times de desenvolvimento possam trabalhar e fazer o deploy de cada serviço de forma independente.
  • Atualizar apenas um serviço para novas tecnologias (como um novo framework, uma nova versão de PHP etc) se torna mais simples, rápido e menos custoso do que readaptar todo o sistema.

Onde o cloud computing entra nisto tudo?

Com a separação de cada serviço, imagine estes serviços trabalhando em paralelo, cada um com sua própria instância e configuração ideal para o funcionamento mais otimizado possível do projeto. Cheguei apenas a esta lista de possibilidades.

  • Otimização de recursos: Você pode elevar ou descer recursos ajustando de acordo com a necessidade específica de cada serviço.
  • Otimização dos custos: Com a maior flexibilidade no ajuste dos recursos você notará que seus custos serão otimizados apenas para o que você realmente utiliza.
  • Otimização do sistema: Como cada instância é isolada você pode configurar o servidor de acordo com a necessidade específica do serviço em questão. Ex.: Você pode configurar um sistema de cacheamento para serviços que demandem informações estáticas, configurar um instância apenas com otimizações para bancos de dados.
  • Estabilidade do sistema: Se um serviço tiver um pico de uso, de memória por exemplo, por conta de um processo, um outro serviço não será penalizado por isto. O mesmo ocorre com o funcionamento do sistema, como um todo, se houver um deploy bugado de apenas um serviço.
  • Escalabilidade: É bem mais rápido e econômico escalar em diversas instâncias um único serviço que já não é suportado mais com apenas uma instância do que o sistema completo.

Como integrante da equipe de desenvolvimento da DialHost, vi e participei da implementação de alguns micro serviços em nossos projetos e conseguimos ver principalmente uma melhora grande na produtividade da equipe em manutenções e maior facilidade para resolver bugs que ocorriam. Conseguimos também dinamizar e escalar de forma mais eficiente ao utilizar nossa solução de Cloud computing colocando apenas os recursos ideais para cada serviços que criamos

Mas, Nem tudo são flores

A principal questão a se avaliar antes de seguir na arquitetura de micro serviços é que o time de desenvolvedores precisa ter o conhecimento para criar um sistema que funcione de forma distribuida. Como em um trabalho em equipe na vida real, se os serviços não trabalharem com sintonia seu sistema não funcionará. A equipe de desenvolvimento fica responsável por criar um mecanismo de comunicação entre estes serviços, afinal eles são serviços isolados que podem trabalhar em conjunto.

As principais IDE’s do mercado hoje em dia, ainda são focadas na criação de aplicações monolíticas. Assim, você não terá muito apoio destas ferramentas para a criação de aplicações distribuídas.

Por fim, se não for muito bem planejado o uso dos microserviços pode ter um efeito reverso na otimização dos seus recursos. É preciso avaliar bem até que ponto você quer ou precisa separar um sistema em diversos micro serviços para que ele não acabe aumentando seu consumo de memória ou até mesmo processamento.

Felipe Moraes
Felipe Moraes

Desde pequeno eu adorei tecnologia e este sentimento me fez estudar e trabalhar com desenvolvimento, design de interfaces e interação. Esta vontade de melhorar e aprender com a tecnologia me fez estar aqui na DialHost desde 2012.

Kubernetes, quais a vantagens em utilizá-lo mesmo depois do docker swarm?

Kubernetes

Kubernetes

No último artigo apresentei um exemplo prático de como montar o docker em um cloud. Hoje avanço um pouco nos conceitos de contêineres trazendo o Kubernetes  para automatizar e gerenciar seus aplicativos em contêineres. Ao fim farei um breve comparativo entre o Kubernetes e o docker Swarm.

Kubernetes

O Kubernetes é uma plataforma desenvolvida pela Google para gerenciar aplicativos em contêineres através de múltiplos hosts de um cluster e assim, ampliar a estabilidade e controle do serviço.

Com ele se tornou possível o que por muito tempo não era possível, nativamente, através do Docker: criar balanceamento de cargas e a migração de contêineres sem perda de dados. Além disto é possível automatizar estas ações para ter alta disponibilidade dos seus serviços.

ReplicaSet

O ReplicaSet é a nova geração do já conhecido Replication Controller, este controlador é responsável por manter a disponibilidade dos seus contêineres (no Kubernetes estes contêineres são encapsulados em Pods, individualmente ou, em alguns casos, em grupos). Ele irá gerenciar a replicação dos Pods de forma que:

  • Se você necessita de 10 Pods sempre rodando, quando um destes Pods cair ou travar, outro Pod será iniciado em seu host para manter o serviço funcionando.
  • Você também pode definir regras para que um novo Pod seja criado sempre que o consumo de CPU de seus Pods, em execução, alcancem 70% de uso, por exemplo.

Lembro que o ReplicaSet não é responsável por definir configurações do seu Pod. Para editar qualquer configuração você deve atualizar o Pod através do Deployment.

Services

Um serviço do Kubernetes é responsável por abstrair das definições lógicas dos Pods, além de definir as regras de acesso a estes Pods. Em outras palavras, aqui atrelamos uma faixa de IP para o ReplicaSet, definimos as regras de acesso do mesmo e configuramos o Load Balance para manter o uso de recursos de cada Pod estável.

Gerenciamento de Storage

Como os Pods são vulneráveis a travamentos e restarts, o Kubernetes trouxe o conceito de volumes independentes, ou seja, possuem suas próprias características de tempo de vida etc. Isto permite que um volume permaneça vivo fora de um contêiner e assim, os dados vinculados a um contêiner “morto” não se percam no meio do caminho. Além disto, um Pod pode utilizar diversos tipos de volumes e inúmeros volumes simultaneamente. Isto porque as regras de como o diretório é e seus conteúdos são determinados pelo tipo de volume utilizado.

Ok. Agora que entendemos um pouco melhor sobre o Kubernetes deu pra ver que ele faz um trabalho de automatização bem completo.

Mas, mesmo depois do Docker ter lançado o Swarm mode, porque o Kubernetes ainda é uma opção mais interessante?

Sem dúvida o Docker swarm é uma opção interessante para criarmos clusters de contêineres e gerenciarmos de forma simples, mas o Kubernetes traz uma proposta bem mais automatizada para fazermos isto.

Enquanto através do Docker Swarm você criará manualmente um cluster, o Kubernetes fará isto tudo automaticamente para você. Ele seguirá suas regras predefinidas (de uso de recursos ou de quantidade de Pods) para manter a estabilidade do serviço.

Um segundo ponto é o isolamento dos volumes que garante que os dados de um Pod estejam da forma que estavam quando ele precisou ser reiniciado.

Não mencionei anteriormente neste post, mas, pelo Kubernetes também é possível definir namespaces para criarmos ambientes isolados de produção e testes. Assim, podemos limitar os recursos de cada ambiente, para que um não interfira no outro.

E para finalizar, um ponto que achei interessante é a flexibilidade dele trabalhar com outros modelos de contêiner que não seja o Docker, como o Rockets (Containers no CoreOS).

Felipe Moraes
Felipe Moraes

Desde pequeno eu adorei tecnologia e este sentimento me fez estudar e trabalhar com desenvolvimento, design de interfaces e interação. Esta vontade de melhorar e aprender com a tecnologia me fez estar aqui na DialHost desde 2012.

Cloud computing para grandes sites em WordPress

Cloud para grandes sites em WordPress

Cloud para grandes sites em WordPress

Estamos em uma era que não podemos negar o poder do WordPress em administrar sites. Muito além dos antigos blogs que víamos sempre por aí, grandes sites, portais e até mesmos lojas
virtuais já podem, e estão utilizando desta plataforma para se estabelecerem online. É o caso de sites como o do ministério da cultura, USP (Universidade de São Paulo) e o próprio iMasters.

Estes tipos de sites tem em comum alguns pontos que não permitem mais funcionar normalmente dentro de uma estrutura compartilhada. A utilização de plugins para controle
e segurança do WordPress e o nível de personalização do próprio WordPress para atender as demandas destes tipos de projetos podem ser um fator a se analisar. Mas sem dúvida o
fluxo de processos, acessos e atualizações de banco de dados que superam, e muito, qualquer estrutura fornecida por planos comuns de hospedagem são o maior fator a se considerar aqui.

Estrutura Dedicada do cloud

Ao contrário das hospedagens compartilhadas uma estrutura em cloud computing permite a disponibilização de recursos dedicados ao projeto. Isto quer dizer, mais segurança, estabilidade e desempenho para o projeto que não será influenciado por outros sites que estão no mesmo servidor.

Nesta estrutura é possível pensar de forma escalada os recursos que vão atender a esta alta demanda do projeto. Sejam recursos para o fluxo normal de utilização do site ou para um momento de pico o cloud computing permite aos administradores de desenvolvedores se precaverem contra ultrapassar o uso de recursos como, memória, espaço em disco e VCPUs conforme o crescimento do uso destes sites.

O patamar de informações que circulam neste tipo de projeto precisa estar muito bem alinhado com os recursos aplicados ao servidor que o sustenta. Um erro aqui pode ser o fim da estabilidade do site.

Separação de banco de dados

O WordPress, como um bom CMS, realiza o controle de informações dentro de banco de dados. Assim, pode não parecer tão claro mas, se preocupar com o acesso, estabilidade e cacheamento desta base de dados é o fator que deve estar no top 1 das preocupações do seu projeto.

A Notícia boa é que com uma estrutura em cloud é possível criar um cluster de banco de dados. Este cluster é responsável por separar em diferentes instâncias sua aplicação web (que vai possuir acesso dos seus usuário) e a escrita/leitura dos dados no banco de dados que serão feitas pela aplicação. Em um post feito no Blog da DialHost expliquei sobre o funcionamento do cluster de banco de dados e como esta arquitetura balanceia a quantidade de requisições ao banco.

Balanceando as cargas de acesso

Do lado da aplicação é possível balancear os processos. Com o balanço, sua rede direcionará os acessos ao WordPress para instâncias separadas de forma uniforme. Por fim você otimizará a utilização dos recursos e evitará sobrecargas que poderiam ocorrer em uma instância única.

Cacheamento dos dados em nível de servidor com Redis

O Redis é um servidor de estruturas de dados que pode ser usado como um servidor de banco de dados. Ele também pode ser utilizado em paralelo com o MySQL para aumentar o seu desempenho. Ele é recomendado para ser configurado como cache. Desta forma ele é capaz de aliviar o consumo que as queries de banco de dados usam para renderizar a página em WordPress.

Como resultado teremos um WordPress renderizado muito mais rápido, o consumo bem menor dos bancos de dados e cache persistente e ajustável.

Como podem ver, este artigo não foca mais naquelas simples soluções baseadas em otimizações feitas por plugins do WordPress que funcionam em diversos blogs menores. Aqui estamos falando  em soluções para
grandes sites que tem acessos e processos bem mais robustos. Nestes casos ter o controle total das requisições, rede, banco de dados são de fato os maiores responsáveis pela estabilidade do site.

Para o próximo artigo, vou escrever sobre a configuração do Redis para manter o cacheamento das informações do WordPress. Então até lá.

Felipe Moraes
Felipe Moraes

Desde pequeno eu adorei tecnologia e este sentimento me fez estudar e trabalhar com desenvolvimento, design de interfaces e interação. Esta vontade de melhorar e aprender com a tecnologia me fez estar aqui na DialHost desde 2012.

Separando sua aplicação do Banco de Dados com instâncias cloud

Instância cloud

Imagem ilustrativa: Separando o banco de dados e aplicação em instâncias cloud  – Freepik

Há algum tempo atrás nós trouxemos para você uma forma avançada de se separar responsabilidades do sistema através do Cluster de banco de dados. Em resumo, esta arquitetura separava seu projeto em instâncias cloud. A ideia é criar um grupo de banco de dados com responsabilidades semelhantes (leitura e escrita) ou não (Só leitura, só escrita) e através de um load balancer podemos balancear a carga de processos em cada servidor.

Hoje explicarei de uma forma mais prática, uma arquitetura que pode encaixar melhor em projetos médios. São comuns exemplos, os mais diversos blogs e lojas virtuais que, apesar de não serem uma americanas, um submarino ou um globo.com, começaram a enfrentar problemas pelo alto fluxo de consultas nos bancos de dados. Estes por sua vez estão trazendo demora ou instabilidade na aplicação web.

Quando fazer a separação em instâncias cloud

Reuni algumas perguntas que você deve se fazer antes de sair contratando ou separando novas instâncias cloud. Afinal, a ideia é otimizar seu sistema mas, não sair separando tudo por mero luxo certo.

  1. Sua aplicação está mais lenta que o normal?
  2. Ela está sofrendo com picos de instabilidade ou até mesmo saindo do ar em determinados momentos do dia?
  3. Durante estes picos e estas demoras, os processos envolvidos são relacionados a uma consulta no banco, ou em salvar algum dado neste?
  4. Ao executar o comando top em seu bash, as estatísticas de uso de recursos estão bem altas e o processo relacionado ao banco de dados está entre os maiores?

Você deve ter percebido que se seu projeto está nesta situação é melhor tomar uma atitude. Então tendo tudo analisado vamos a parte prática.

Mão na massa! Colocando meu Banco de dados em outra instância cloud

Para isto, utilizarei o painel do DialCloud+. Com ele você conseguirá configurar cada instância com os recursos necessários a cada projeto.

Para ilustração deixo este esquema de como funcionará este exemplo de arquitetura. Basicamente estamos deixando seu banco dados dedicado em uma instância com seus recursos próprios.

Banco de dados dedicado em uma instância cloud

Arquitetura com banco de dados dedicado

Com esta imagem em mente, podemos seguir ;).

Abaixo podemos ver que toda a aplicação se encontra em apenas uma instância. Nesta instância temos instalados o SO, o apache, o MySQL, PHP e entre diversas outras aplicações. O caso é que, como citado acima, eu identifiquei que meu banco de dados começou a consumir grande parte da minha memória e acaba por utilizar minhas 4 vCPUs disponíveis o que deixa todo o meu sistema em cheque.

 

instâncias cloud

Tela de instâncias do DialCloud +

É claro que neste exemplo terei de optar por aumentar um pouco meus recursos. Mas, simplesmente aumentá-los não seria suficiente já que isto não evita que meu banco de dados, em um momento de desespero, acabe por utilizar 6vCPUs. Por isto, a ideia aqui é pegar este banco de dados e migrar ele para outro servidor.

Para que seu sistema não fique fora durante todo o tempo da migração e para minimizar todo e qualquer impacto, vamos pegar os novos recursos e montar uma instância de banco de dados mínima. Esta estrutura servirá de base para configurarmos o que virá a ser nosso servidor final.

Nova instância

Tela de nova instância do DialCloud +

Como pode ver montei uma pequena instância com os recursos mínimos para que eu pudesse configurar meu novo servidor de banco de dados.

Migrando meu banco de dados

E ai vem a grande dica! Como agora tenho um servidor que será responsável apenas por receber e responder consultas de banco, posso simplesmente ignorar a instalação de vários módulos e aplicações de servidor que acabam por consumir um pouco do meu processamento e instalar apenas por exemplo o MySQL. Menos recurso para aplicações, mais recurso para o banco.
Ao terminar a instalação da nova instância eu preciso exportar o banco que está em produção e então importar no servidor novo. Apesar de rápido, este é o momento que exige maior atenção, pois terei que colocar meu serviço em manutenção momentânea para que não perca nenhum dado no meio do processo. Afinal enquanto faço isto, meus usuários estariam utilizando meu app.

Outra dica é não fazer isto em um dia ou horário de pico de acesso, assim você terá mais tranquilidade para fazer o processo.

Agora eu preciso fazer minha aplicação comunicar com este novo banco de dados, mas não se preocupe. Com a criação da nova instância minha tela de network mostra uma nova rede interna que foi criada entre estas 2 instâncias cloud. Basta eu pegar o ip interno referente ao servidor de banco de dados e colocar no host das configurações de banco de dados da minha aplicação.

Tela de rede interna no DialCloud +

Tela de rede interna no DialCloud +

Para garantir mais proteção aos meus dados, vou configurar o acesso do ip externo apenas para a instância de aplicação. Faço isso configurando o Port forwarding e no caso do serviço do DialCloud+ libero o acesso externo no firewall (Esta é uma proteção a mais disponibilizada na DialHost gratuitamente) através do Outbound Firewall.

Tela de Port Forwarding no DialCloud +

Tela de Port Forwarding no DialCloud +

Realocando recursos

Tá mas, meu processo que exigia mais recursos tem bem menos recursos. Bem, como eu disse antes, esse era um servidor base para a migração. Agora é só ir nas configurações das instâncias e escalonar os recursos. Assim, você poderá destinar mais para seu banco de dados e menos para sua aplicação.

Concluindo

Esta arquitetura possui uma distribuição mais simples se comparada com a de cluster de dados. Por ser mais simples, ela pode ser mais comum para o dia a dia de diversos projetos. Ainda assim, ela é uma ótima opção pois propicia:

  • Menor custo com recursos de máquina.
  • Melhor distribuição das responsabilidades do servidor o que falicita seu escalonamento.
  • Maior segurança dos dados, já que seu banco de dados não terá acesso por outro lugar que não sua aplicação.
Tenha controle e flexibilidade nos seus recursos com DialCloud +. Servidores em cloud com load balancing, VPN e todo o controle de rede que você precisa. Saiba Mais.

 

DialHost
DialHost

Contamos com nosso DataCenter no Brasil de alta qualidade, estabilidade e confiança para hospedar seu site. Utilize poderosas ferramentas para otimizar o uso do seu serviço e seja sempre atendido de forma rápida e clara pelo nosso atendimento 24h.

É possível ter segurança em Servidores Cloud?

segurança em Cloud computing

Imagem ilustrativa sobre segurança em Cloud computing – fonte Freepik

Antes de dar minha opinião, explicarei algumas dicas para serem aplicadas em seu servidor cloud. Em seguida demonstrarei algumas funcionalidades utilizando a ferramenta da DialHost que auxilia na configuração de algumas regras que melhoram a segurança.

Primeiramente temos sempre que manter uma atenção especial na segurança de nossos servidores. Pois há uma evolução constante dos tipos de ataque e defesa.
As tecnologias evoluíram. E com elas, os hackers que cada vez mais ágeis e habilidosos, encontram brechas para burlar sistemas de gerenciamento e informações sigilosas de empresas e instituições.

Mas para que você tenha mais garantias contra estes tipos de ataques seguem algumas dicas para ajudar na proteção do seu servidor

Mantenha atualizado os pacotes e kernel do servidor

Ao deixar seu kernel desatualizado você perde todas as atualizações de segurança, melhorias de estabilidade, atualizações de drivers e funcões que foram desenvolvidas nas novas versões.

Instale um detector de brute force

O ataque brute force é uma técnica hacker que costuma utilizar um dicionário de usuários e senhas para realizar o acesso a algum sistema. Através destas combinações ele tenta constantemente realizar acessos até que um destes dados sejam validados e finalmente o sistema seja aberto.

O detector de brute force, por outro lado fica analisando tentativas sucessivas de acessos vindas de um mesmo IP. Através desta repetição ele bloqueia o acesso do IP malicioso e assim, mata o processo iniciado pelo robô hacker. Um exemplo de sistema detector de brute force é o Fail2Ban.

Desabilite o acesso Root via SSH

Sabemos que o acesso root permite mais facilidades para o usuário avançado, mas como já dizia o tio Ben “Grandes poderes trazem grandes responsabilidades”. Por isso, desabilite este usuário via SSH e crie usuários apenas com as permissões necessárias para o seu projeto e manutenção do mesmo.

root

Crie chaves para o acesso via SSH

Ao fazer um acesso via SSH utilizando chaves de acesso, você garante que seu acesso terá um conjunto longo e complexo de caracteres. Por outro lado o acesso através apenas de senha tendem a ser previsíveis ou fáceis para ataques do tipo brute force.

Mude a porta de acesso do SSH

A alteração da porta de acesso do ssh é importante para retardar a atuação de portscaner que buscam primeiramente as portas default dos serviços como “22,23,53,80,443,21”. Alterando sua porta de acesso estes scaners vão cair em uma porta fechada.

Para realizar esta alteração recomendo que utilize o port forwarding assim seu acesso interno se mantém na porta original, mas seu acesso público pode ser redirecionado para outra porta como 7021, por exemplo.

Busque informações de segurança para os serviços ativados

É normal que serviços famosos possuam em seus próprios cores soluções de segurança ou mesmo pacotes que auxiliam na segurança. Serviços como Apache, Nginx entre outros vão te disponibilizar constantemente novas opções de segurança. Mas, é importante que quem esteja gerenciando suas instâncias fique sempre informado sobre novas soluções. Assim, você pode ficar mais tranquilo contra ataques hackers.

Instale um Firewall

Na DialHost, por exemplo, ao contratar um plano DialCloud+, é disponibilizada uma ferramenta para configuração do Firewall. Assim, você pode garantir mais segurança nas suas instâncias uma forma simples.

Outra análise que vale informar é que as instâncias estão protegidas em um rede totalmente privada. Outros clientes não tem nenhuma comunicação com suas instâncias criadas.

Veja como é simples a criação das regras

Tela do sistema DialCloud - Adicionando regra de segurança do Firewall

Tela do sistema DialCloud – Adicionando regra de Firewall

No campo IP, será exibido o seu IP Público para os acessos.
CDIR: Você informar um range ou único IP permitido para acessar a porta.
Start Port: O inicio de uma série de portas ou a definição de uma única porta
End Port: A última porta a ser liberada ou a mesma informada para o início.
Protocolo: Define qual tipo de protocolo como TCP, UDP ou ICMP.

Após adicionar as regras desejadas, o resultado ficará como abaixo.
Simples de ser visualizado, configurado e reconfigurado.

Tela do sistema DialCloud - inbound Firewall

Tela do sistema DialCloud – inbound Firewall

Concluindo

Sobre a pergunta proposta no inicio, na minha opinião não podemos afirmar que estamos 100% protegidos contra os invasores. Este é um trabalho onde temos que estar atentos e atualizados às práticas mais atuais para nos proteger.

Os invasores sempre vão preferir servidores desatualizados e que possuam mais brechas para a invasão. Dificultar as invasões com o Firewall e outras ferramentas de proteção é uma atividade contínua dos administradores dos servidores.

Referências

http://www.makeuseof.com/tag/5-reasons-update-kernel-linux/
http://www.liquidweb.com/kb/what-is-brute-force-detection-bfd/
https://www.vivaolinux.com.br/dica/Alterando-a-porta-do-servico-SSH

Tenha controle e flexibilidade nos seus recursos com DialCloud +. Servidores em cloud com load balancing, VPN e todo o controle de rede que você precisa. Saiba Mais.

 

Márcio Rubens
Márcio Rubens

Sou Analista de TI na DialHost, pós-graduado em Gestão de Segurança da Informação pela PUC-MG e graduado em Gestão da Tecnologia da Informação pela UNI-BH.