Após um longo período sem escrever nada no meu blog, estou de volta e trago um assunto bem interessante para quem gosta de Wi-fi.
Apenas um breve comentário, Fiz algumas mudanças na minha vida profissional recentemente mas foi no intuito de adequar ao meu objetivo de focar mais e mais em Wi-fi.
Recentemente deixei uma posição de Analista de Suporte na empresa AT&T e assumi uma posição de Consultor na empresa Promonlogicalis. Posição voltada para projetos de redes Wireless, mas estou lá para o que der e vier. Quando o assunto é tecnologia de redes, qualquer coisa me interessa.
Em um dos meus projetos tive a necessidade de implantar um Cluster de Controllers usando HA. A partir das versões 7.3 a Cisco implantou a feature nas Wireless Lan Controllers. Até então, Controllers eram implantadas de forma independentes e na configuracao do AP, em High Availability, era feito os apontamentos para Controllers diferentes afim de conseguir a redundância.
Obviamente, a possibilidade de Configurar o AP com até três Controllers continua nas Controllers em HA, não houve qualquer diferença nesse aspecto. Essa imagem foi retirada de uma Controller que possui suporte para HA.
A tela acima nos dá a possibilidade de apontar os APs para até três Cluster de Controller em HA ou para um Cluster e para Controllers em Standalone e assim por diante. Depende da arquitetura que se tenha. O que estou explicando aqui é que a mudança não alterou outros aspectos já existentes.
A função dessa feature é óbiva. Possibilitar que Controllers trabalhem no esquema Active/Standby, assim como os Firewalls ASA já fazem.
A versão que utilizei em meu projeto é a 7.4. Nessa versão ainda não é possível fazer Client SSO, apenas AP SSO. Isso significa que a tabela de APs é totalmente replicada entre as Controllers mas a de Client não. Ou seja, nas versões anteriores a 7.5, se houver falha em uma Controller, os usuários conectados terão que se reconectar. O ponto positivo é que não há um downtime dos APs. Como a reconexão de Clients é muito rápido, o ambiente se recupera com muita facilidade e rapidez.
A configuração de High Availability é simples. Na verdade, se for comprado uma das Controllers como HA SKU, ela já será a standby por default. Caso compre duas controllers normais, veremos a frente que é preciso definir a relação Primary/Secondary.
Antes das configurações é preciso solicitar ao time de Cabling que passe um cabo adicional interligando as duas Controllers. Esse cabo é um cado direto normal mas é exigido em ambiente com HA. As portas a serem conectadas é identificada com as letras RD de Redundanty Port, com pode ser visto abaixo:
Porta superior esquerda: Service Port
Porta inferior esquerda: Redundanty Port. (Seta em Azul )
Service Port é usado para gerenciamento da Controller. Seria como uma porta console porem com conexão IP. A Redundancy Port tem a função de "Linkar" as duas Controller que farão parte do cluster.
A Cisco recomenda que a comunicação entre as duas Controllers para redundancia seja feita em camada dois, não é recomendado roteamento nessa comunicação. Se o projeto prever Controller em datacenters diferentes, é preciso ter um link Lan-to-Lan entre ambos possibilitando uma interligação em camada dois.
Uma vez realizado a conexão física, o próximo passo é configurar.
As Controller com suporte a HA, possui um tipo especial de Interface chamada de Redundancy Management Interface :
Essa interface precisa ser configurada com um endereço IP. É preciso que esse IP esteja na mesma subnet da Management Interface. Em termos de endereçamento é apenas isso. Agora vamos a configuração do Cluster em si:
Na tela acima temos os parâmetros mostrados. O primeiro deles, Redundancy Management IP é o que informei na figura anterior. Quando o passo anterior for executado, nesse campo que agora aparece com um valor default de 0.0.0.0 irá aparecer com o IP previamente configurado.
O campo Peer Redundancy Mgmt IP é o IP da outra Controller. Ou seja, é o Redundancy IP da outra Controller que fará parte do cluster. Esse apontamento precisa ser feito em ambas.
O IP 169.x.x.x não precisa e não tem com ser alterado. A própria Controller irá preenche-lo usando os octetos do endereço adicionado em Redundancy Mgmt IP.
Após esses passos, é preciso definir a Controller como Primary ou Secondary, caso ela não seja por default através da lincença HA-SKU.
Apenas esclarecendo que mesmo com HA SKU, a opção de definir como primary e secondary permanece, porem, não é necessário se preocupar. No momento da sincronização, elas saberão se entender sozinhas.
Por último temos o campo AP SSO. Apenas altere esse campo após todas as configuração prévias estiverem ok. Também é importante validar se as Controllers estejam com conectividade entre si, com o Gateway, ou seja, com a rede em geral.
Após a alteração do AP SSO de disabled para enabled, em ambas as Controllers, elas irão rebootar e o processo de formação do Cluster terá início. Caso alguma coisa não esteja correta e impeça a sincronização, o acesso às Controller pela interface Web irá ficar prejudicado. Eu tive esse problema e a solução foi acessar por Console e desativar o AP SSO na mão usando o comando :
config redundancy mode SSO disable
E com isso concluímos esse Post. Como pode ser visto, o processo é simples de compreender e configurar, porém, o resultado é muito vantajoso.
Como já disse muitas e muitas vezes, rede Wireless há muito deixou de ser uma rede secundária. Impactos na rede Wireless resultam em muitos tickes abertos e muita reclamação porque afeta e muito o cotidiano das pessoas hoje em dia. Em qualquer ambiente corporativo e mesmo fora dele, as pessoas querem mais e mais estarem conectadas a rede.
No comments:
Post a Comment