Configuração do servidor do memcached do nginx mongodb mongdb Ubuntu [duplicado]

3

Eu tenho construído um aplicativo da Web PHP usando as seguintes técnicas nos últimos dois meses:

  • PHP 5.3.4
  • MongoDB
  • MySql

Acabei de receber meu servidor dedicado executando o Ubuntu 10.4 LTS x64 com o seguinte hardware:

  • velocidade de rede de 100 Mbit
  • SSD de 120 GB
  • 16 GB de RAM a 1600 MHZ
  • CPU AMD FX 6100 de 6 núcleos a 1400 MHz cada núcleo (total de 3600 MHz)
  • Linux Kernel 2.6.33 (para suportar o ajuste SSD)
  • Ubuntu 10.4 LTS x64

O conteúdo estático para o aplicativo da Web é (descompactado, não-eliminado) no total de 200kb. O aplicativo da Web do PHP exigia escalabilidade, ele pode obter muito tráfego no início.

Agora tenho algumas perguntas:

  • O que devo configurar em termos de proteção DDOS, não tenho concorrentes, o projeto é subterrâneo e desconhecido, então o que devo considerar? O que me ajudaria com isso, já que há tantas coisas por aí, como usar um mod Nginx ou usar o Iptables? E como posso configurá-los?
  • Como posso calcular a largura de banda e quanto tráfego o servidor pode gerenciar?
por Mike Vercoelen 08.03.2012 / 23:40

2 respostas

1

Proteger contra o DDOS pode ser difícil, porque uma alta proporção do tempo que o ISP fica sem recursos (firewalls com estado ou largura de banda) e vai afundar o seu bloco de IPs.

Se o seu DDOS esperado, em seguida, escolher um ISP que pode oferecer prevenção DDOS e sabe como lidar com cargas de alto tráfego, pergunte-lhes exemplos e sistema-los no lugar que pode ajudar. Desligar você não é uma resposta.

Esteja preparado para bloquear netblocks de máquinas de ddos agressivas ou blocos de rede de ddos com o iptables ou seu próprio firewall upstream.

se apenas alguns ip's usarem mais de 90% dos seus recursos, bloqueie-os.

Desenvolva métodos para detectar clientes abusivos (acessar determinados scripts ou páginas, solicitações estranhas, solicitações de páginas fora de ordem, etc, etc. e bloqueá-los).

considere o uso de qos de entrada / saída para controlar a largura de banda de saída de forma justa para os clientes.

considere dividir o banco de dados, a lógica do aplicativo e a veiculação da Web em hardware diferente.

considere um balanceador de carga com alguns nós de cache de carne para absorver pequenos invasores. Mas cuidado, entrar em uma guerra de recursos com o seu atacante não é a melhor idéia, eles vão ganhar! : - (

considere adicionar uma camada de cache entre o aplicativo e o banco de dados, que deve manter a carga do servidor de banco de dados para solicitações repetidas

se o ddo estiver segmentando conteúdo estático, não scripts da Web que exigem recursos do banco de dados, considere algo como um CDN (cloud flare) que oculta o endereço IP real do restante da Internet e ajuda a distribuir a carga geograficamente. você obtém conteúdo mais rápido entregue aos seus usuários e, como efeito colateral, você obtém proteção para os dodôs.

Se você não precisa do UDP, faça com que seu ISP bloqueie o tráfego na fronteira. se você precisar apenas da porta 80 e 443, faça com que seu ISP bloqueie isso na permissão da rede. Se o seu ISP não sabe o que UDP ou portas estão obtendo um novo ...: -).

hospede seu dns em uma infraestrutura separada, com alguém grande que possa lidar com ddos. Se você precisa hospedar o dns, coloque-o em uma infraestrutura separada e em uma rede diferente.

se você estiver usando SSL, certifique-se de que consegue lidar com o sucesso da CPU dos handshakes SSL. Aceleradores SSL são caros. Talvez desenvolva um sistema em que somente clientes pagos ou clientes autenticados registrados possam se conectar via SSL. O mesmo vale para as conexões da porta 80, certifique-se de que seus usuários estejam registrados antes de terem acesso ao aplicativo. Poderia interromper ataques de dodos profundos em seu aplicativo.

de qualquer forma, parece divertido. o que você está fazendo?

    
por 09.03.2012 / 00:10
0

Os comentários e outras respostas são completamente sólidos, mas eu também recomendaria colocar o Varnish na frente como um cache para conteúdo estático (e um pouco dinâmico), bem como proxy reverso. O NGINX também faz isso, mas o verniz é melhor nessas duas áreas.

Isso basicamente descreve a infra na minha antiga empresa, onde executamos essa configuração para aplicativos PHP e Rails.

    
por 16.05.2012 / 04:18