Archive

Archive for the ‘NLB’ Category

Sobre DNS Policies–Windows Server 2016–volume2–Balanceamento de Carga

11 de abril de 2017 Deixe um comentário

Saudações,

Dando continuidade a nossa série de posts sobre DNS Policies, hoje vou relembrar um post que publiquei a um tempo atrás falando sobre o uso do balanceamento de carga de aplicações.

Para quem ainda não leu o primeiro post desta série, segue abaixo o link:

Sobre DNS Policies – Volume1 – Teoria

1. Planejamento do Balanceamento de carga

Vamos clarificar que, o planejamento para alta disponibilidade e sizing de suas aplicações, você não deve somente se basear no que vamos falar aqui. Você precisa ter em mente os objetivos e tipos de acesso que serão necessários para a sua realidade. O balanceamento de carga pode ser feito via NLB Windows, Failover Clustering ou NLB via hardware (este um recurso mais indicado para aplicações que recebem muitos acessos). No caso de high availability em cloud, verifique as questões de elasticidade em termos desenvolvimento e veja como seu cloud provider trabalha em relação a isso.

Enfim, o balanceamento de carga via DNS Policies deve ser avaliado quanto sua eficácia para o negócio que seu aplicativo visa entregar a um departamento e/ou cliente final. Você precisa estar certo de que esta é a melhor opção para seu cenário.

2. Estudo de caso

Vamos propor aqui, como no artigo original publicado anteriormente, um estudo de caso que nos dará a base para a solução a ser implementada:

2.1. Tenho 4 servidores de aplicação – 1 em São Paulo, 1 no Rio de Janeiro, 1 em Fortaleza e  1 em Belo Horizonte

2.2. Fortaleza e Belo Horizonte possuem links com menos banda que SP e RJ

2.3. Essa aplicação vai atender a todo acesso que vier em qualquer uma das filiais da empresa

3. Cenário

Para atender a esta demanda, temos o seguinte desenho de solução:

 

image

4. Solução técnica

Com o exposto acima, vamos ver agora de forma prática como o DNS Policies nos ajuda a entregar essa solução de forma rápida e tudo via PowerShell!!

Primeiro vamos criar os escopos de zona. É a partir deles que a política vai se orientar para aplicar o que queremos. Para cada localidade onde tenho um servidor de aplicação vou crirar um Scope Zone.

Vou noema-los da seguinte forma:

São Paulo: SP_Scope

Rio de Janeiro: RJ_Scope

Fortaleza: For_Scope

Belo Horizonte: BH_Scope

Como fica as linhas de comando PowerShell para isso:

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “SP_Scope”

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “RJ_Scope”

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “For_Scope”

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “BH_Scope”

image

Com os Scope Zones criados, vou criar um registro tipo A dentro destes escopos, ou seja, cada escopo estará apontando para o IP do back-end server da localidade correspondente:

Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “AppServer” –IPv4 “10.10.0.10” –ZoneScope “SP_Scope”

Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “AppServer” –IPv4 “10.10.1.10” –ZoneScope “RJ_Scope”

Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “AppServer” –IPv4 “10.10.2.10” –ZoneScope “For_Scope”

Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “AppServer” –IPv4 “10.10.3.10” –ZoneScope “SP_Scope”

image

Agora que já temos os Zone Scopes criados e seus respectivos registros, vamos criar a política que fará o balanceamento de carga via DNS Policies:

Add-DnsServerQueryResolutionPolicy -Name "AppServerPolicy" -Action ALLOW – -ZoneScope "SP_Scope,3;RJ_Scope,3;For_Scope,2;BH_Scope,2" -ZoneName "uilson.net"

image

No comando acima observa-se que ao fim de cada Scope Zone foi colocado uma vírgula e um número (Ex: SP_Scope,3). Isto vai definir que para a cada 10 requisições feitas para o host “appserver.uilson.net”, teremos as 3 primeiras sendo direcionadas para o servidor em São Paulo, as próximas 3 para o servidor do Rio de Janeiro, as 2 seguintes para o servidor em Fortaleza e as 2 últimas para o servidor de Belo Horizonte. Dessa forma conseguimos balancear a carga entre as 3 localidades, respeitando os limites de link de cada uma delas.

5. Conclusão

Este post foi publicado novamente para seguir a série que começamos em 03/abril/2017 sobre DNS Policies. No próximo post falaremos sobre Gerenciamento de tráfego de Rede usando políticas de DNS.

Espero que você tenha gostado e que este conteúdo possa ajuda-lo em suas tarefas diárias.

Abraços

Uilson

Usando o DNS Policies do Windows Server 2016 TP para balanceamento de carga

24 de junho de 2015 4 comentários

Saudações

Um das grandes mudanças que vem com o Windows Server 2016 TP não se resume somente ao que tenho mostrado nesse blog acerca do Web Application Proxy e AD Federation Services.

Hoje vamos abrir mais as possibilidades e compartilhar sobre algumas mudanças que o serviço de DNS também ganhou.

O Windows Server 2016 Technical Preview traz o DNS policies, uma nova feature na role DNS server.

As políticas são criadas para controlar como o DNS Server controla as requisições baseado em diversos parâmetros. O pessoal do Network Blog da Microsoft escreveu uma série de artigos onde detalham as funcionalidades do DNS Policies entre elas a parte de traffic management, deployment do split-brain DNS e criação de DNS query filters usando as políticas.

Neste post vou partilhar com vocês algo que eles também já detalharam, o balanceamento de carga de aplicações via DNS Policies. Para quem usa DNS no Windows Server 2008 ou 2012, trata-se de uma evolução do Round Robin.

Os procedimentos a seguir foram feitos em laboratório montado por mim usando como base de estudo o artigo do pessoal do Network Blog, no endereço abaixo:

http://blogs.technet.com/b/networking/archive/2015/05/20/application-load-balancing-using-dns-server-policies.aspx

Para ilustrar melhor, vamos imaginar um ambiente em que eu tenho meus servidores de aplicação espalhados em 4 datacenters. São Paulo, Rio de Janeiro, Fortaleza e Belo Horizonte. Lembrando que esse é um ambiente fictício. Estou compartilhando aqui o que aprendi estudando o artigo acima citado e o laboratório que fiz.

A diferença deste laboratório para o que foi postado no link acima é que, no meu caso, tenho em São Paulo e Rio de Janeiro, servidores que podem receber mais carga de acessos do que nas outras duas filiais.

No exemplo pelo pessoal do Network Blog, eles possuem 3 ambientes, sendo o primeiro o que tem mais condições de receber a caga de requisições em relação aos dois últimos.

No caso do nosso post aqui, vamos nos ater ao desenho abaixo:

image

Usando por base o exemplo acima, o DNS Policies irá distribuir as requisições entre os servidores fazendo com que as 3 primeiras requisições sejam direcionadas para São Paulo, as próximas 3 para Rio de Janeiro, as 2 seguintes para Fortaleza e as próximas 2 para Belo Horizonte. O processo se repete constantemente.

Agora, tecnicamente falando, como isso pode ser feito? Vamos listar os procedimentos:

Criar os zone scopes

O zone scope é uma instância única em um zone. Um zone pode conter diversos escopos e esses escopos podem conter diversos registros. No nosso laboratório, iremos criar os escopos SP_Scope (para São Paulo), RJ_Scope (para Rio de Janeiro), For_Scope (para Fortaleza) e BH_Scope (para Belo Horizonte). Lembrando que nosso zone tem o nome de uilson.net.

Todos os procedimentos listados aqui são feitos via Power Shell:

Criando o Zone Scope para São Paulo com o comando Add-DnsServerZoneScope -ZoneName "uilson.net" -Name "SP_Scope"

image

Repetir os processos para os sites do Rio, Fortaleza e Belo Horizonte:

Add-DnsServerZoneScope -ZoneName "uilson.net" -Name "RJ_Scope"

Add-DnsServerZoneScope -ZoneName "uilson.net" -Name "For_Scope"

Add-DnsServerZoneScope -ZoneName "uilson.net" -Name "BH_Scope"

Inserir os registros nos Zones Scopes

O próximo passo do nosso laboratório é inserir o registro dos web servers nos zones scopes criados no passo anterior.

Dentro dos zone scopes do domínio uilson.net vou inserir o registro “app” para que a chamada “app.uilson.net” retorne a aplicação a sere balanceada pelo DNS Policies.

O registro app será criado em cada zone scope com o IP referente ao web server da localidade conforme abaixo:

SP_Scope – 10.10.0.10

RJ_Scope – 10.10.1.10

For_Scope – 10.10.2.10

BH_Scope – 10.10.3.10

O primeiro registro a ser criado será no zone scope SP_Scope:

Add-DnsServerResourceRecord -ZoneName "uilson.net" -A -Name "app" -IPv4Address "10.10.0.10" -ZoneScope "SP_Scope"

image

Repetir o comando para os demais sites, alterando IP e Zone Scope name:

Add-DnsServerResourceRecord -ZoneName "uilson.net" -A -Name "app" -IPv4Address "10.10.1.10" -ZoneScope "RJ_Scope"

Add-DnsServerResourceRecord -ZoneName "uilson.net" -A -Name "app" -IPv4Address "10.10.2.10" -ZoneScope "For_Scope"

Add-DnsServerResourceRecord -ZoneName "uilson.net" -A -Name "app" -IPv4Address "10.10.3.10" -ZoneScope "BH_Scope"

Criação da política

Agora que nosso laboratório já tem os zone scopes e os registros criados em cada um deles, nos resta agora criar a política que irá distribuir as requisições entre os DNS Servers de acordo com o que foi planejado no começo deste post.

Relembrando que em nosso laboratório fictício, o hardware dos servidores de São Paulo e Rio de Janeiro têm condições de receberem um número maior de requisições (ambos ficarão com 30% da carga) e os servidores de Fortaleza e Belo Horizonte, com um hardware e menor poder de carga, ficam com 20% das requisições cada um.

A política é configurada através do comando abaixo:

Add-DnsServerQueryResolutionPolicy -Name "AppServerPolicy" -Action ALLOW – -ZoneScope "SP_Scope,3;RJ_Scope,3;For_Scope,2;BH_Scope,2" -ZoneName "uilson.net"

image

Repare na sintaxe do comando PS que após cada zone scope name vem uma vírgula e um número:

SP_Scope,3

RJ_Scope,3

For_Scope,2

BH_Scope,2

Desta forma eu defino que São Paulo receberá as 3 primeiras requisições, o Rio de Janeiro as próximas 3, Fortaleza receberá as 2 seguintes e Belo Horizonte as 2 próximas. O fluxo de repete constantemente.

Vale ressaltar que o processo de balanceamento de carga pelo DNS Policies melhorou muito em relação ao DNS Round Robin. Entretanto, pelo que vi no meu laboratório, algumas limitações permanecem…tais como a impossibilidade de determinar se um host está ou não disponível. Ao menos não encontrei nada que mudasse esse quadro.

Tendo em vista ainda estarmos na versão Technical Preview do Windows Server 2016, imagino que nem tudo o que estamos vendo permanecerá como está. Mudanças podem ocorrer no decorrer do período de testes.

Conclusão

Neste post mostrei pra você como configurar o serviço de balanceamento de carga de aplicações via DNS do Windows Server 2016 Technical Preview, utilizando a nova feature DNS Policies.

Expliquei como se cria os escopos de zona, adição dos registros e criação das políticas em face ao planejamento inicial.

Recomendo o uso deste recurso em aplicações de uso interno de sua corporação. O mesmo não se aplica a acessos externos.

Assim que eu reestruturar meu laboratório vamos retornar aos testes com a nova versão do Web Application Proxy no Windows Server 2016 TP e também o Application Request Router.

Espero que o conteúdo seja útil!

Abraços

Uilson

Erro 105–NLB Cluster–Timer starvation has been detected

17 de fevereiro de 2014 Deixe um comentário

Saudações,

Queria, antes de qualquer coisa, agradecer a todos que participaram da minha palestra sobre Segurança para Redes Microsoft no evento de WebCasts realizado pelo grupo MTAC (Microsoft Technical Audience Contributor).

Espero que tenham gostado e que o conteúdo possa ajudar no dia a dia!

Essa semana me deparei – na prática – com um erro que ainda não tinha visto e  somente tinha lido a respeito.

Durante um consumo excessivo em seu servidor WEB ou para quem ainda usa Forefront TMG em balanceamento de carga, o erro abaixo pode ocorrer:

image

Como lidar com isso? Porque acontece?

Em resumo este problema pode ocorrer em algumas situações:

1. Ataques de origens internas 

Um ataque vindo de uma ou várias estações infectadas, enviando muitas requisições ao servidor gerando um DoS e vindo consequentemente a parar o serviço, causando transtorno para os usuários que precisam do acesso a este servidor, seja ele proxy ou WEB Server.

Neste caso analise bem as origens, ou seja, de onde as requisições vêm e tente determinar se realmente se trata de um ataque.

Caso você determine que uma ou várias estações estão enviando um número absurdo de requisições a um determinado ambiente em NLB, tome as precauções de prache, tais como, scan, análise do acesso em si, ou seja, mitigar o problema a partir da origem.

Em alguns casos, seu proxy ou web server pode estar sofrendo um ataque por conta de um problema em seu roteador ou swtiche que, recebe a requisição e após um travamento ou algo do gênero (não posso adentrar muito nesse mérito, pois, não tenho skill em routers), pode reter requisições de determinadas origens fazendo as mesmas entrar em looping, repetindo constantemente o acesso ao servidor, fazendo com que o erro 105 ocorra.

Neste caso, o suporte da equipe de networking é fundamental para determinar e resolver o problema, uma vez que, ao se descobrir os IP´s de origem, você, ao analisar a estação verá que a mesma não tem nenhum tipo de malware, ou, no caso de um ataque a um servidor de proxy, descobrirá que o acesso requerido não deveria causar tamanho dissabor!

O único problema aí é que, ultimamente, quando se trata de análises de requisições para WEB via um proxy (Forefront TMG ou outro qualquer) em que se pede análise em devices de rede, os responsáveis pelos mesmos se sentem ofendidos como se, analisar o seu device de rede fosse uma ofensa pessoal…portanto, você que lê este post e atua com routers, não leve isso para o lado pessoal, em uma análise mais complexa, muitos pontos da infra devem ser verificados e os devices de rede não ficam de fora…ou não deveriam ficar…rs.

2. Insuficiência de recursos

Como pode ser visto na imagem acima, a explicação para o Erro 105 no NLB também pode ser referente a insuficiência de recursos, ou seja, a quantidade de equipamentos em balanceamento podem não ser suficientes para suportar toda carga de acessos.

Neste caso, adicione um ou mais nodes a sua estrutura de servidores. Para situações em que o erro 105 ocorra em estruturas de WEB Servers, siga o passo a passo do KB abaixo:

http://msdn.microsoft.com/en-us/library/cc726481(v=ws.10).aspx

Neste KB, além da definição do erro 105, você encontra o passo a passo de como incluir mais nodes em sua estrutura de WEB Servers em NLB.

Para o caso de servidores de proxy, siga as instruções do fabricante de seu produto. No caso de Forefront TMG, instale um novo servidor com as mesmas características daqueles que já estão em produção, faça o deploy do Forefront TMG e o insira no array produtivo. Mais informações sobre isso, faça uma pesquisa neste blog na caixa localizada no canto superior direito para encontrar posts relacionados.

Para evitar esse tipo de problema, faça sempre um planejamento sério e eficaz, prevendo crescimento e dando ao cliente um tempo de vida útil para o ambiente (seja ele qual for).

Para mais detalhes sobre planejamento de estruturas de TI, façam também uma pesquisa neste blog.

Espero que o conteúdo possa ajudar!

Gostaria de agradecer meu amigo Gilberto Okoti pela explicação a respeito da parte dos devices de rede e que ajudaram na solução do problema e montagem deste post!

Um abraço!

Uilson

 

%d blogueiros gostam disto: