O Zookeeper é um componente crítico da operação de alta disponibilidade do Hadoop. Este último se protege limitando o número de conexões máximas (MaxConns = 400). No entanto, o Zookeeper não se protege de forma inteligente, ele recusa as conexões assim que o limiar é alcançado. Nesse caso, os componentes principais (regiões HBASE / HDFS ZKFC) não poderão mais inicializar uma conexão e o serviço será degradado ou indisponível!
É muito fácil fazer um ataque de DOS a Zookeeper. Por outro lado, como a maior parte da instalação do Zookeeper está dentro de zonas confiáveis ou semi-confiáveis, esses ataques geralmente são involuntários. É o suficiente para um desenvolvedor não responder e lançar um código personalizado que abre sessões de zookeeper em loop sem fechá -las. Nesse caso, o Zookeeper está comprometido e todos os componentes com ele.
Soluções
Várias soluções alternativas podem ser configuradas de forma independente ou em conjunto.
Utilização des observadores
Os observadores são nós específicos de Zookeepers:
- Eles não participam de quorum
- Eles sincronizam os nós participantes
- Eles transferem pedidos de gravação para nós participantes
Portanto, eles possibilitam aumentar o número de nós sem desacelerar o processo eleitoral.
Usando iptables
É possível se proteger de dose externos via iptables. De fato, podemos limitar o número de conexões na porta do Zookeeper (2181) por endereço IP. Isso possibilita colocar um limite inferior ao Zookeeper Maxconns e, assim, bloquear um endereço específico sem bloquear o acesso de outra máquina.
Exemplo
Imagine a seguinte topologia de cluster:
- 3 nós de borda:
edge1.adaltas.com, edge2.adaltas.com edge3.adaltas.com - 3 nós mestres:
master1.adaltas.com, master2.adaltas.com, master3.adaltas.com - n nós trabalhadores: n’interviennent pas dans ce cas
- Essas máquinas estão localizadas na sub -rede:
10.10.10.0/24
Os nós do Masters são usados como quorum eletivo e as bordas como observadores para aumentar a carga.
NB: O número par de nós não é um problema, apenas 3 são participantes
Configuração do Zookeeper
Configuramos essas configurações (/etc/zookeeper/conf/zoo.cfg):
Nos nós mestres:
clientPort=2181
maxClientCnxns=200
peerType=participant
server.1=master1.adaltas.com:2888:3888
server.2=master2.adaltas.com:2888:3888
server.3=master3.adaltas.com:2888:3888
server.4=edge1.adaltas.com:2888:3888
server.5=edge2.adaltas.com:2888:3888
server.6=edge3.adaltas.com:2888:3888Nos nós da borda:
clientPort=2181
maxClientCnxns=200
peerType=observer
server.1=master1.adaltas.com:2888:3888
server.2=master2.adaltas.com:2888:3888
server.3=master3.adaltas.com:2888:3888
server.4=edge1.adaltas.com:2888:3888
server.5=edge2.adaltas.com:2888:3888
server.6=edge3.adaltas.com:2888:3888Nos nós mestres, é proibido se comunicar com máquinas externas na porta 2181 (apenas a rede local é permitida) através da seguinte regra iptables:
-A INPUT -m state --state NEW -m tcp -p tcp -s 10.10.10.0/24 --dport 2181 -j ACCEPTAssim, essas instâncias do Zookeeper são acessadas apenas por nossos serviços e processos internos.
Os nós de borda limitam a comunicação com máquinas externas na porta 2181 a 100 conexões IP simultâneas por meio da regra:
iptables -A INPUT -p tcp --syn --dport 2181 -m connlimit --connlimit-above 100 --connlimit-mask 32 -j REJECT --reject-with tcp-resetConfiguração Hadoop
Para serviços Hadoop (HDFS ZKFC, HBase Master, etc.), a seguinte sequência de conexão é especificada:
master1.adaltas.com:2181,master2.adaltas.com:2181,master3.adaltas.com:2181Para configurações “Client” (recipientes de fios, HBase do cliente, aplicativos de terceiros, etc.), a string é especificada:
edge1.adaltas.com:2181,edge2.adaltas.com:2181,edge3.adaltas.com:2181Assim, quando um trabalho externo ou aplicativo é lançado, ele não pode saturar o quorum e não compromete o estado do cluster.
Vá além, Silotagem de Observadores nós
Se um aplicativo “fraudulento” externo usar a string edge1.adaltas.com:2181,edge2.adaltas.com:2181,edge3.adaltas.com:2181 Então é possível que satura os 3 nós observados. Assim, embora o cluster permaneça estável, alguns serviços não estarão disponíveis, pois os clientes não poderão mais visualizar o Zookeeper.
Podemos limitar o impacto da saturação dos observadores, decompondo a cadeia em várias substringas que serão especificadas nas configurações do cliente. Exemplo:
- Corrente 1:
edge1.adaltas.com, edge2.adaltas.com - Corrente 2:
edge1.adaltas.com, edge3.adaltas.com - Corrente 3:
edge2.adaltas.com, edge3.adaltas.com
Assim, se a String 1 estiver saturada, o Edge3 permanecerá disponível. Os aplicativos direcionados ao canal 2 e 3 não serão bloqueados.
