terça-feira, 17 de janeiro de 2017

Configuração de Link P2P em Bridge no Cisco Aironet

Olá Pessoal,

Tradicionalmente os dispositivos Access Point (AP) são utilizados como concentradores em redes sem fio com o propósito de viabilizar uma célula em seu entorno com área de cobertura para que haja comunicação com múltiplos dispositivos clientes de modo ponto-a-multiponto, motivo pelo qual os APs são equipados com antenas omnidirecionais com largura de feixe de 360° no plano horizontal (azimute). Apesar dessa ser a aplicação mais comum, há casos em que é necessário alterar esse comportamento convencional de modo a configurar dois APs em bridge para viabilizar a comunicação ponto-a-ponto, por exemplo na interligação sem fio à distância entre duas unidades remotas de uma empresa (vide figura). 

Nesses casos são acopladas nos APs antenas externas que tenham menor largura de feixe e com maior ganho (dBi) em uma determinada direção. A escolha da antena direcionada mais adequada vai depender da distância entre as duas unidades remotas, destacando que quanto maior o ganho da antena, maior será seu alcance e menor será a largura do feixe no plano horizontal. Por exemplo, antenas parabólicas são as que têm maior ganho (de 20 a 30 dBi) e podem alcançar vários quilômetros de distância (por volta de 50km), dependendo da obstrução no caminho entre as antenas. 


Obs.: Esteja ciente de que antenas parabólicas de alto ganho não devem ser utilizadas sem que o enlace de radiofrequência tenha sido devidamente projetado para irradiar sinal efetivo (EIRP) dentro dos limites legais do seu domínio regulatório, levando em consideração a potência de transmissão, a perda no cabo e demais componentes e o ganho da antena. Conforme Resolução 506/2008 da Anatel, no Brasil o EIRP máximo permitido na frequência de 2,4GHz é de até 30dBm (1000mW) em cidades com até 500.000 habitantes ou de até 26dBm (400mW) em cidades com mais de 500.000 habitantes. Qualquer enlace que esteja operando acima desses parâmetros deve ser licenciado junto à agência. 

O objetivo deste artigo é listar os passos necessários para configurar dois Aironet da Cisco em modo bridge para que seja possível estabelecer um enlace ponto-a-ponto entre duas unidades remotas, com base no cenário apresentado na figura anterior. Repare que as duas unidades pertencem à mesma sub-rede lógica em camada 3 (rede), o que deixa evidente que a conexão em modo bridge nada mais é do que uma ligação em camada 2 (enlace). É como se os APs fossem switches nas unidades remotas que estivessem interligados através de um cabo. Ocorre que na maioria dos casos não é possível fazer a passagem dos  cabos na via pública e a locação de um link dedicado não é barato (quando há disponibilidade no local), então fazer essa ligação através do meio não-guiado (wireless) acaba sendo uma opção atrativa.

Obs.: Também é possível isolar cada unidade em sua respectiva sub-rede lógica (camada 3). Nesse caso, o link ponto-a-ponto entre os dois APs é configurado como sendo uma sub-rede /30 independente das outras duas sub-redes das unidades remotas, de forma que cada AP terá um dos IPs disponíveis na sub-rede /30. O AP de cada unidade remota será diretamente conectado em um roteador de borda, ao invés de um switch. Se essa estratégia for adotada, é importante ter em mente que nos roteadores de borda deverá ser adicionada uma rota para a sub-rede lógica da outra unidade. 

Abaixo o leitor encontra os comandos necessários para configurar ambos os APs através dá interface de linha de comando (CLI) do IOS. Observe que o AP-A foi definido como root bridge e que o AP-B foi definido como non-root bridge, sendo que o canal do enlace é definido apenas no AP raíz. Assim que o link for efetivamente estabelecido, o LED dos Aironet em ambas as unidades mudará sua cor de verde para azul, indicando que os dois APs estão associados entre si. 

AP-A(config)# interface bvi1
AP-A(config-if)# ip address 192.168.0.201 255.255.255.0
AP-A(config-if)# exit
AP-A(config)# ip default-gateway 192.168.0.1
AP-A(config)# dot11 ssid BRIDGE
AP-A(config-ssid)# authentication open
AP-A(config-ssid)# authentication key-management wpa ver 2
AP-A(config-ssid)# wpa-psk ascii PASSWORD
AP-A(config-ssid)# exit
AP-A(config)# interface dot11radio0
AP-A(config-if)# station-role root bridge
AP-A(config-if)# channel 6
AP-A(config-if)# encryption mode ciphers aes-ccm
AP-A(config-if)# ssid BRIDGE
AP-A(config-if)# no shut
AP-A(config-if)# end

AP-B(config)# interface bvi1
AP-B(config-if)# ip address 192.168.0.202 255.255.255.0
AP-B(config-if)# exit
AP-B(config)# ip default-gateway 192.168.0.1
AP-B(config)# dot11 ssid BRIDGE
AP-B(config-ssid)# authentication open
AP-B(config-ssid)# authentication key-management wpa ver 2
AP-B(config-ssid)# wpa-psk ascii PASSWORD
AP-B(config-ssid)# exit
AP-B(config)# interface dot11radio0
AP-B(config-if)# station-role non-root bridge
AP-B(config-if)# encryption mode ciphers aes-ccm
AP-B(config-if)# ssid BRIDGE
AP-B(config-if)# no shut
AP-B(config-if)# end

Façam seus testes...

Samuel.

quarta-feira, 11 de janeiro de 2017

Marcação DSCP e QoS em Roteadores Cisco

Olá Pessoal,

O modelo DiffServ de serviços diferenciados é flexível de acordo com o perfil das aplicações, uma abordagem alinhada com o conceito de nível de serviço (SLA) em que são previamente acordadas as classes de serviços com base em parâmetros como volume de tráfego, disponibilidade e outros que possam assegurar o desempenho adequado dos serviços em execução na infraestrutura de uma rede. O modelo DiffServ é o mais utilizado para implementar QoS porque exige menos dos roteadores do que o modelo IntServ de serviços integrados que requer protocolos inteligentes para que os roteadores possam providenciar a reserva prévia de recursos entre dois pontos (cliente/servidor). 

RFC 2597 e RFC 2598 descrevem, respectivamente, aquilo que é denominado Assured Forwarding (AF) e Expedited Forwarding (EF), ambos mecanismos de classificação de diferentes níveis de tráfego para serviços diferenciados no modelo DiffServ. Existem quatro classes AF que variam de AF1X até AF4X, sendo que o primeiro número é a prioridade da classe. Quanto maior o número de prioridade, então maior é a importância daquele perfil de tráfego no ambiente. O segundo número (representado por X) varia de 1 a 3 e diz respeito à preferência de descarte dos pacotes, sendo que números maiores têm maior probabilidade de serem descartados. Já a classe EF faz referência ao encaminhamento expresso, ou seja, aquele perfil de tráfego que possui baixa tolerência a qualquer tipo de atraso (tradicionalmente o tráfego de voz). A tabela abaixo traz um resumo de todas as combinações possíveis dos códigos das classes AF e EF.

|-----------------------------------------------------------------|
| Descarte | Classe 1 | Classe 2 | Classe 3 | Classe 4 | Expresso |
|-----------------------------------------------------------------|
| Baixo    |   AF11   |   AF21   |   AF31   |   AF41   |          |
| Médio    |   AF12   |   AF22   |   AF32   |   AF42   |    EF    |
| Alto     |   AF13   |   AF23   |   AF33   |   AF43   |          |
|----------|----------|----------|----------|----------|----------|

O modelo DiffServ propõe um sistema de códigos para classificação de tráfego que é denominado DSCP (DiffServ Code Point) e consiste em sobrescrever os primeiros 6 primeiros bits do campo ToS (Type of Service) do cabeçalho IP, Dessa maneira, cada código diz respeito a uma classe de tráfego que pode receber tratamento diferenciado pelo administrador. A figura abaixo traz um resumo de alguns dos principais códigos DSCP, inclusive com o mapeamento das principais classes AF/EF previamente apresentadas e sugestões de associações com aplicações típicas do cotidiano:

Fonte: Internet (sem especificação de autoria)  
É fato que no primeiro momento parece ser bastante informação teórica para assimilar, então aproveito o cenário simplista da topologia abaixo para exemplificar a configuração prática de alguns desses conceitos, particularmente em relação à marcação de pacotes de uma aplicação qualquer em execução na porta TCP/3050 com o código AF41 (ou DSCP 34) para fins de priorização desse tráfego, além de marcação de um host qualquer com o código AF13 de baixa prioridade.


O objetivo não é discutir cada uma das linhas abaixo com detalhes dos elementos de uma política de QoS, por isso recomendo a leitura do artigo intitulado "Policy-Map na Restrição da Taxa de Tráfego". Apenas vale relembrar que basicamente o processo de configuração de QoS em dispositivos Cisco consiste em três etapas: (i) classificação do tráfego via class-map, (ii) definição da política através de policy-map e (iii) aplicação da policy-map na entrada/saída de alguma interface.

!--- ACL 101 (Referente Tráfego do Host 192.168.0.109 (Host 109)
access-list 101 permit ip host 192.168.0.109 any
access-list 101 permit ip any host 192.168.0.109

!--- ACL 102 (Referente Tráfego do Servidor de Banco de Dados (Firebird)
access-list 102 permit tcp any any eq 3050
access-list 102 permit tcp any eq 3050 any

!--- Classificação do Tráfego da ACL 101 na Class-Map HOST-109
class-map match-all HOST-109
   match access-group 101
   exit

!--- Classificação do Tráfego da ACL 102 na Class-Map FIREBIRD
class-map match-all FIREBIRD
   match access-group 102
   exit

!--- Definição de Políticas na Policy-Map QOS
policy-map QOS
   class HOST-109
      set dscp af13
      police rate 256000 bps
      exit
   class FIREBIRD
      set dscp af41
      end

!--- Aplicação da Policy-Map na Saída da Interface F0/0
interface f0/0
   service-policy output QOS 

Nesse exemplo foram definidas duas class-map, uma vinculada à ACL 101 que faz referência ao host 192.168.0.109 (class-map HOST-109) e outra vinculada à ACL 102 que faz referência à aplicação TCP/3050 (class-map FIREBIRD). Observem que nesse exemplo é realizada apenas a marcação dos pacotes em um roteador isolado, sendo que sua utilização em cenário real também requer a leitura prévia dessa marcação para posterior aplicação de ações/políticas nos demais roteadores intermediários da rede.

Na sequência, a policy-map denominada QOS possui duas políticas, uma relacionada ao host 192.168.0.109 que marca seus pacotes com o código DSCP AF13 (baixa prioridade) e também aplica uma restrição de banda de apenas 256k; e outra relacionada a uma aplicação em execução na porta TCP/3050 que apenas faz a marcação dos seus pacotes com o código DSCP AF41 (alta prioridade) sem aplicar nenhuma outra ação. 

Por fim, o comando "show policy-map" pode ser utilizado para visualizar todas as políticas que foram configuradas em um determinado roteador da rede, lembrando que essas políticas são individuais de cada roteador (distribuídas), ainda que exista um esforço centralizado de definição dessas políticas no ambiente da empresa. Ou seja, é importante estar atento no momento de fazer as configurações das políticas de QoS nos roteadores da infraestrutura porque facilmente a escrita equivocada de regras pode implicar em roteadores contendo políticas contraditórias entre si (ambiguidade).

!---
!--- Visualização de Políticas Previamente Configuradas
!---
R1# show policy-map
  Policy Map QOS
    Class HOST-109
      set dscp af13
      police rate 256000 bps burst 8000 bytes
        conform-action transmit 
        exceed-action drop 
    Class FIREBIRD
      set dscp af41



Façam seus testes...

Samuel.

quarta-feira, 2 de novembro de 2016

Controlador de Domínio do SAMBA 4 no Debian GNU/Linux

Olá Pessoal,

Em outro artigo intitulado "Configuração Básica do SAMBA em Servidores Linux" o leitor passou pela experiência básica de como fazer o simples compartilhamento de diretórios e arquivos através do SAMBA para integrar ambientes heterogêneos com máquinas Linux e Windows. No entanto, é importante destacar que o SAMBA 4 vai muito além do simples compartilhamento e permite que o servidor Linux assuma o papel de controlador de domínio (DC). Assim é possível ingressar máquinas Windows no serviço de diretório do servidor Linux para que a gerência dos objetos de um domínio (computadores, contas de usuários, políticas, etc) seja centralizada sem a necessidade do MS Windows Server, o que implica em economia na licença do sistema operacional do servidor e também da quantidade de clientes da rede (CAL).




O objetivo deste artigo é listar as etapas necessárias para instalar o SAMBA 4 (e seus complementos) para transformar um servidor Debian GNU/Linux no controlador do domínio denominado AULA.LOCAL. Nesse exemplo assumiremos que nosso controlador de domínio será configurado com o IP 192.168.221.1/24. Uma etapa preliminar é definir estaticamente no arquivo /etc/hosts o mapeamento do nome do servidor que posteriormente será configurado como controlador de domínio. Nessa etapa criaremos um mapeamento estático (NOME<>IP) em que o nome da máquina já será composto com o sufixo do domínio (FQDN) que será utilizado posteriormente. Por causa desse mapeamento o SAMBA irá sugerir o nome de domínio AULA.LOCAL durante sua instalação. 

###--- em /etc/hosts -------------------------
127.0.0.1       localhost
192.168.221.1   samba-dc   samba-dc.aula.local
###--- fim do arquivo ------------------------

1) Instalação do Servidor SAMBA DC

Assim como nos artigos anteriores, estou considerando que o servidor está instalado com a distribuição Debian GNU/Linux (ou seus derivados, como o Ubuntu). A primeira etapa consiste na instalação do pacote denominado samba para que o Linux possa ser posteriormente configurado como controlador de domínio. Também é necessário instalar vários pacotes com outros serviços, a exemplo do DNS (winbind), do Kerberos (krb5-user), etc. Apesar de ser bastante coisa, essa tarefa é simples e rápida através do APT:

root@samba-dc:/# apt-get update
root@samba-dc:/# apt-get install samba smbclient ntp krb5-user winbind ldap-utils acl attr

Durante a instalação irá aparecer um diálogo (modo texto) solicitando 3 informações:

- Nome do Domínio                               : AULA.LOCAL
- Endereço do Servidor Kerberos de Autenticação : 127.0.0.1
- Endereço do Servidor Administrativo           : 127.0.0.1

2) Configuração do NTP p/ Sincronização do Relógio das Máquinas

A próxima etapa é fazer alguns ajustes no serviço NTP responsável pela sincronização do relógio da máquina que será responsável por sincronizar os relógios de todas as demais máquinas do domínio. Depois de criado o diretório ntp_signd com as devidas permissões, é necessário adicionar algumas linhas ao final do arquivo de configuração localizado em /etc/ntp.conf.

root@samba-dc:/# install -d /var/lib/samba/ntp_signd/
root@samba-dc:/# chown root:ntp /var/lib/samba/ntp_signd
root@samba-dc:/# chmod 750 /var/lib/samba/ntp_signd/

###--- em /etc/ntp.conf ------------------------
(...) Conteúdo Omitido
### Adicionar Configuracoes Abaixo p/ SAMBA 4 DC
ntpsigndsocket /var/lib/samba/ntp_signd/
restrict default mssntp
disable monitor
###--- fim do arquivo --------------------------

Depois desses ajustes, basta reiniciar o serviço NTP:

root@samba-dc:/# service ntp restart

O status do serviço NTP pode ser verificado através dos seguintes comandos:

root@samba-dc:/# service ntp status
root@samba-dc:/# ntpq -p

3) Parada de Serviços em Execução

Antes de fazer a configuração do domínio propriamente dito através do processo de provisionamento do SAMBA, é necessário parar serviços que são automaticamente executados logo depois da instalação dos pacotes, além de "remover" o arquivo original de configuração do SAMBA (/etc/samba/smb.conf):

root@samba-dc:/# service smbd stop
root@samba-dc:/# service nmbd stop
root@samba-dc:/# service winbind stop
root@samba-dc:/# mv /etc/samba/smb.conf /etc/samba/smb.conf.bak

4) Provisionamento do Domínio

Uma das etapas mais importantes é o provisionamento do domínio em que serão utilizadas ferramentas automatizadas do próprio SAMBA para preparar nosso servidor como controlador do domínio AULA.LOCAL. A principal ferramenta é o comando samba-tool que serve como frontend responsável por manipular o OpenLDAP (backend), simplificando muito a tarefa de configuração. 

root@samba-dc:/# samba-tool domain provision --use-rfc2307 --interactive

Ao digitar o comandoo sistema irá indagá-lo e sugerir as seguintes configurações que podem ser aceitas através da tecla <ENTER>:

- Realm                       [AULA.LOCAL] 
- Domain                      [AULA]
- Server Role                 [DC]
- DNS Backend                 [SAMBA_INTERNAL]
- DNS Forwarder IP Address    (IP do DNS da REDE)
- Administrator Password      (SENHA FORTE)

Obs.: Os parâmetros trazidos nas chaves [] são sugeridos pelo samba-tool e podem ser aceitos. O servidor DNS integrado ao controlador de domínio será responsável pelos mapeamentos dos nomes na rede interna, de forma que todas as máquinas Windows a serem ingressadas no domínio devem ser configuradas para apontar seu DNS primário para o IP do servidor SAMBA (192.168.221.1). Caso exista(m) outro(s) servidor(es) DNS na rede (por ex. BIND), responsável por exemplo pelo mapeamento de nomes externos, pode ser feito o apontamento através do DNS Forwarder.

5) Ajustes Finais

É hora de fixar as configurações de DNS do servidor no arquivo /etc/resolv.conf e aplicar a característica de imutabilidade (+i) no mesmo para que seu conteúdo não seja mais dinamicamente atualizado. Também vamos copiar o template do arquivo de configuração do Kerberos que vem com o pacote samba (/var/lib/samba/private/krb5-conf) para o diretório /etc para que a autenticação no domínio possa funcionar. Por fim, vamos reiniciar o serviço do SAMBA como controlador de domínio.

###--- em /etc/resolv.conf ---
search aula.local
nameserver 192.168.221.1
###--- fim do arquivo --------

root@samba-dc:/# chattr +i /etc/resolv.conf
root@samba-dc:/# cp /var/lib/samba/private/krb5.conf /etc
root@samba-dc:/# service samba-ad-dc restart

6) Verificação

A primeira maneira de verificar se o SAMBA está em execução é:

root@samba-dc:/# service samba-ad-dc status
Active: active (running) since (...) 

Para fazer uma verificação mais apurada, vale testar a resolução de nomes internos de alguns registros automaticamente criados pelo controlador de domínio, além de testar a resolução de nomes externos:

root@samba-dc:/# host -t A aula.local
aula.local has address 192.168.221.1

root@samba-dc:/# host -t SRV _kerberos._udp.aula.local
_kerberos._udp.aula.local has SRV record 0 100 88 samba-dc.aula.local

root@samba-dc:/# host -t SRV _ldap._tcp.aula.local
_kerberos._tcp.aula.local has SRV record 0 100 88 samba-dc.aula.local

root@samba-dc:/# host www.debian.org
www.debian.org has address 200.17.202.197
www.debian.org has IPv6 address 2801:82:80ff:8009:e61f:13ff:fe63:8388

Finalmente vamos testar a autenticação do Kerberos:

root@samba-dc:/# kinit administrator@AULA.LOCAL
Password for administrator@AULA.LOCAL: <Senha do Administrador do Domínio>
Warning: Your password will expire in 41 days on (...)

root@samba-dc:/# klist
(...) Informações de Validade do Ticket (Kerberos)


7) Administração do Domínio

Pronto, o servidor SAMBA já está em operação como controlador do domínio AULA.LOCAL. A partir deste ponto o domínio pode ser administrador via interface de linha de comando (CLI) através da ferramenta samba-tool. São várias as opções para administração do domínio via samba-tool, por isso é recomendada a leitura do manual da ferramenta (man samba-tool). Abaixo trago uma breve relação de alguns dos comandos mais comuns:

samba-tool user list                  ### exibe todos os usuários do domínio
samba-tool user add <NOME>            ### adiciona um novo usuário
samba-tool user del <NOME>            ### remove um usuário existente
samba-tool user enable <NOME>         ### habilita um usuário desabilitado
samba-tool user disable <NOME>        ### desabilita uma conta de usuário

Caso algum usuário esqueça sua senha, o coomando abaixo pode ser utilizado para resetá-la de forma que o usuário seja obrigado a alterá-la no próximo login:

samba-tool user NOME --newpassword=SENHA --must-change-at-next-login  

Outra opção bastante atrativa é utilizar a ferramenta RSAT (Remote Server Administration Tools) que pode ser baixada gratuitamente na página da Microsoft e instalada em qualquer máquina executando o Windows (versões 7, 8 ou 10). A vantagem dessa abordagem é que a administração do domínio é feita pela mesma interface gráfica das tradicionais Ferramentas Administrativas do Windows Server, aproveitando todo o conhecimento do administrador. O RSAT pode ser baixado através dos links abaixo:

- Windows 7: https://www.microsoft.com/pt-br/download/details.aspx?id=7887 
- Windows 8: https://www.microsoft.com/pt-br/download/details.aspx?id=28972
- Windows X: https://www.microsoft.com/pt-BR/download/details.aspx?id=45520

Obs.: Depois de baixado o RSAT deve ser instalado no Windows e manualmente adicionado como recurso extra. Nos links oficiais da Microsoft onde o RSAT pode ser baixado o leitor encontra as instruções para instalação da ferramenta. 

Façam seus testes...

Samuel.

segunda-feira, 10 de outubro de 2016

Espelhamento de Discos em Servidores Debian GNU/Linux

Olá Pessoal,

Uma prática bastante comum em servidores é a combinação de múltiplos discos físicos em arranjos lógicos denominados RAID (Redundant Array of Independent Discs), principalmente para fins de disponibilidade dos dados aramazenados em mais de um disco e também para fins de desempenho, uma vez que dados armazenados em múltiplos discos implicam em maior velocidade de leitura. 

Há diversas modalidades de RAID, sendo a mais simples delas o RAID-1 que faz o espelhamento de discos, ou seja, mantém em um segundo disco físico uma cópia exata do primeiro disco físico. Em caso de falha de um dos discos, o conteúdo continua disponível através do outro disco e o administrador pode providenciar a troca do disco defeituoso para que haja sincronização total do conteúdo no novo disco.

O RAID normalmente é implementado através de hardware, sendo gerenciado por uma controladora de discos que pode ser configurada através da BIOS (ou UEFI) da máquina antes mesmo do início de instalação do sistema operacional. Essa é a opção mais recomendada porque apresenta melhor desempenho, no entanto só está disponível em hardware particularmente desenvolvido para servidores. Como o Linux se trata de um sistema operacional aberto e gratuito, ele acaba sendo a opção natural em ambientes menores que não têm recursos para aquisição de hardware adequado para seus servidores. Nesses casos, frequentemente são utilizados computadores tradicionais que não possuem hardware apropriado com uma controladora que suporte a implementação de RAID na BIOS/UEFI.

Apesar dessa limitação de equipamento, a boa notícia é que também existe a opção de configurar o RAID por software através dos sistemas operacionais modernos, ainda que o desempenho seja pior que a solução profissional implementada por hardware. Especificamente no caso do Debian GNU/Linux, a configuração de RAID pode ser facilmente implementada durante o próprio processo de instalação do servidor, desde que a máquina tenha pelo menos dois discos físicos.

A configuração de RAID-1 na instalação do Debian consiste basicamente em criar partições idênticas nos dois discos físicos e em marcá-las com o rótulo "physical volume for RAID", ao invés de escolher um sistema de arquivos (figura 1). Depois disso é possível acessar a opção "Configure Software RAID" na própria ferramenta de particionamento do Debian e selecionar as duplas partições que serão agrupadas em RAID-1. Ao terminar de criar os agrupamentos, será possível observar o(s) novo(s) disco(s) lógico(s) do RAID na tabela de partições, onde o administrador deverá fazer a indicação do sistema de arquivos e dos pontos de montagem (figura 2).

Figura 1. Indicação de RAID em 2 Discos Físicos (Antes)
Figura 2. Particionamento de Disco Lógico RAID-1 (Depois)

A implementação do RAID-1 na instalação do Debian GNU/Linux é bastante simples, mas como lidar com o sistema operacional em caso de falha de um dos discos? Como fazer a inserção do novo disco no arranjo lógico e sincronizar os dados em ambos os discos? O objetivo desse artigo é listar as ações necessárias para recompor o RAID em caso de falha de um disco. 

Consideremos um servidor que possui dois HDs (/dev/sda e /dev/sdb) arranjados em RAID-1, cada um deles contendo 3 partições com capacidade de armazenamento apenas simbólica conforme apresentado nas figuras acima. Abaixo trago novamente o esquemático das partições:

/dev/sda1 > +/- 0.6 GB (SWAP)
/dev/sda2 > +/- 7.0 GB (/)
/dev/sda3 > +/- 1.0 GB (/home)

/dev/sdb1 > +/- 0.6 GB (SWAP)
/dev/sdb2 > +/- 7.0 GB (/)
/dev/sdb3 > +/- 1.0 GB (/home)

O RAID-1 de ambos os HDs foi configurado durante o processo de instalação do servidor Linux Debian, através da ferramenta de partição do próprio instalador (na opção Configure Software RAID), dando origem aos seguintes arranjos lógicos do tipo multi-disk (/dev/mdX):

/dev/md0 = /dev/sda1 + /dev/sdb1 (SWAP)
/dev/md1 = /dev/sda2 + /dev/sdb2 (/)
/dev/md2 = /dev/sda3 + /dev/sdb3 (/home)

Enquanto os discos estão operando normalmente, o arranjo lógico dos discos físicos em RAID-1 será responsável por realizar o espelhamento de todo o conteúdo armazenado no primeiro disco também no segundo disco, garantindo que sempre exista uma cópia de segurança dos dados. Caso haja pane em qualquer um dos discos, será necessário repor fisicamente o HD defeituoso e inserí-lo manualmente no arranjo lógico do RAID-1 para que todo o conteúdo do disco em operação possa ser sincronizado novamente no novo HD. 

Por exemplo, em caso de pane no segundo HD (/dev/sdb) será necessário:

1) Reparticionar o novo HD (/dev/sdb) com o mesmo esquema do disco em operação (/dev/sda)

root@Linux:/# sfdisk -d /dev/sda | sfdisk /dev/sdb

Feito isso, é sempre prudente verificar se o novo HD possui as mesmas partições do original:

root@Linux:/# fdisk -l /dev/sda
root@Linux:/# fdisk -l /dev/sdb

2) Adicionar as partições do novo HD (/dev/sdX#) ao RAID (/dev/mdX):

root@Linux:/# mdadm --manage /dev/md0 --add /dev/sdb1 
root@Linux:/# mdadm --manage /dev/md1 --add /dev/sdb2
root@Linux:/# mdadm --manage /dev/md2 --add /dev/sdb3

Feito isso, é possível verificar que o RAID será ressincronizado (espelhamento dos discos), de forma que o novo HD seja preenchido com uma cópia exata do conteúdo armazenado no HD original:

root@Linux:/# cat /proc/mdstat

Personalities : [raid1]
md2  :  active raid1 sda3[0] sdb3[1]
        965056 blocks super 1.2 [2/2] [UU]

md1  :  active raid1 sda2[0] sdb2[1]
        6832128 blocks super 1.2 [2/2] [UU]

md0  :  active (auto-read-only) raid 1 sda1[0] sdb1[1]
        584128 blocks super 1.2 [2/2] [UU]

A saída exibe o status de cada arranjo lógico do tipo multi-disk, sendo que o conteúdo dos colchetes destacados em amarelo exibem o status individual de cada um dos discos físicos. Por exemplo, a saída [UU] indica que ambos os HDs estão em operação, enquanto que a saída [U_] indicaria que o segundo disco físico não está em operação. 

Façam seus testes...

Samuel. 

quarta-feira, 28 de setembro de 2016

Configuração de Ether-Channel e Trunk em Roteadores Cisco

Olá Pessoal,

Assim como a configuração de agregação de interfaces físicas é uma prática comum em links tronco (trunk) de switches para fins de disponibilidade e balanceamento de carga, essa mesma configuração é igualmente importante em roteadores que fazem roteamento inter-VLAN. Para exemplificar a configuração de uma agregação de links em roteadores Cisco, utilizarei o cenário apresentado na figura abaixo em que é necessário configurar roteamento inter-VLAN entre duas sub-redes compostas por máquinas de duas VLANs diferentes, de maneira similar ao exemplo que trago no Lab06 (intitulado Configuração de Switches e VLANs) do livro Laboratórios de Tecnologias Cisco.

A diferença é que no laboratório do livro o roteador está conectado ao switch através de uma única interface física, enquanto que nesse exemplo será configurada uma agregação lógica em duas interfaces físicas do roteadores. Essa prática não só é recomendada para fins de disponibilidade em caso de falha de um dos links, mas também para obter melhor desempenho porque múltiplas VLANs estão atreladas a um único trunk entre o switch e o roteador naquilo que chamamos de router on a stick


Nas linhas abaixo trago as configurações necessárias no roteador para que o roteamento inter-VLAN funcione no cenário proposto, com destaques em amarelo para aqueles comandos que remetem à configuração da agregação propriamente dita. 

Router# configure terminal
Router(config)# interface port-channel 1
Router(config-if)# exit
Router(config)# interface range g0/0 - 1
Router(config-if-range)# channel-group 1
Router(config-if-range)# no shut
Router(config-if(range)# exit
Router(config)# interface po1.10
Router(config-subif)# encapsulation dot1q 10
Router(config-subif)# ip address 192.168.10.254 255.255.255.0
Router(config-subif)# exit
Router(config)# interface po1.20
Router(config-subif)# encapsulation dot1q 20
Router(config-subif)# ip address 192.168.20.254 255.255.255.0
Router(config-sub-if)# exit 
Router(config)# 

Para completar esse laboratório, abaixo trago as configurações do switch:

Switch# configure terminal
Switch(config)# vlan 10
Switch(config-vlan)# name VERDE
Switch(config-vlan)# exit
Switch(config)# vlan 20
Switch(config-vlan)# name VERMELHO
Switch(config-vlan)# exit
Switch(config)# interface range f0/1 - 3
Switch(config-if-range)# switchport access vlan 10
Switch(config-if-range)# exit
Switch(config)# interface range f0/4 - 6
Switch(config-if-range)# switchport access vlan 20
Switch(config-if-range)# exit
Switch(config)# interface range g0/1 - 2
Switch(config-if-range)# switchport mode trunk
Switch(config-if-range)# channel-group 1 mode on
Switch(config-if-range)# exit
Switch(config)# 

Façam seus testes...

Samuel. 

terça-feira, 27 de setembro de 2016

Instalação do Banco de Dados Firebird em Servidores Linux

Olá Pessoal,

O objetivo deste artigo é listar a simples instalação e configuração do Firebird em Servidores Linux. O Firebird é um popular Banco de Dados derivado do código do Borland InterBase 6.0. Trata-se de uma ferramenta open-source e gratuita que está disponível para as mais diversas plataformas, seja Linux, Windows, Mac OS, FreeBSD ou Solaris. Como ele possui código aberto e não tem licença, é possível utilizá-lo em qualquer tipo de aplicação sem pagar nada por isso, mesmo em aplicações comerciais. A ferramenta é considerada madura porque sua tecnologia de base tem mais de 20 anos. 




Assim como nos artigos anteriores que escrevi sobre Linux, estou considerando que o servidor está devidamente instalado com a distribuição Debian GNU/Linux (ou seus derivados, como o Ubuntu). A primeira etapa consiste na instalação do pacote denominado firebird2.5-superclassic para que o Linux possa ser posteriormente configurado como servidor de banco de dados para aplicações clientes. Essa tarefa é simples e rápida através do APT:

root@Linux:/# apt-get update
root@Linux:/# apt-get install firebird2.5-superclassic

Obs.: O Firebird está disponível nas arquiteturas SuperClassic (firebird2.5-superclassic) e Classic (firebird2.5-classic). Vamos utilizar a arquitetura SuperClassic porque ela é mais indicada para uso em máquinas SMP (múltiplos núcleos de processamento). 

Durante a instalação do Firebird será aberto um diálogo para definir uma nova senha para o usuário padrão SYSDBA, sendo que frequentemente essa senha é masterkey. Essa senha pode ser redefinida a qualquer momento através do comando abaixo:

root@Linux:/# dpkg-reconfigure firebird2.5-superclassic

Feito isso, o Firebird já deve estar devidamente instalado e em execução no servidor, embora ainda não esteja permitindo acessos remotos através da rede. Para verificar se o serviço está em execução, basta utilizar o comando abaixo. Caso o administrador queira parar ou iniciar o serviço manualmente, esse mesmo comando pode ser utilizado alterando o parâmetro status por start (iniciar) ou stop (parar).

root@Linux:/# service firebird2.5-superclassic status

Apenas a título de observação, outra forma de verificar se o serviço está no ar é localizar manualmente os processos em execução no servidor, particularmente observando os processos denominados fb_smp_server e fbguard. O processo fbguard é um monitorador que protege a execução do servidor (fb_smp_server), de forma que o guardião automaticamente executa uma nova instância do processo servidor em caso de falha. 

root@Linux:/# ps aux | grep fb

(...) Exemplo de Saída do Comando

firebird  1064  (...) /usr/sbin/fbguard (...)
firebird  1065  (...) /usr/sbin/fb_smp_server
root      1226  (...) tty1 (...) grep fb

Depois de instalado, o arquivo de configuração do Firebird fica localizado em /etc/firebird/2.5/firebird.conf, sendo bem documentado e organizado em diferentes seções para facilitar sua configuração. Por padrão o servidor Firebird somente permite acesso a partir da máquina local (localhost) e é executado na porta 3050/TCP. Para permitir o acesso remoto ao servidor através de outras máquinas na rede, é necessário localizar e comentar a seguinte linha no arquivo de configuração do firebird:

###--- em /etc/firebird/2.5/firebird.conf
#RemoteBindAddress = localhost

Obs.: O acesso através da rede não irá funcionar se existir algum firewall no servidor ou mesmo no meio do caminho que esteja bloqueando comunicação na porta 3050/TCP. 

Uma vez que o Firebird esteja devidamente instalado e em execução, é possível criar novas bases de dados ou mesmo instalar o pacote com exemplos para testar a conexão remota. Através do comando abaixo utilizaremos o APT para instalar o pacote com exemplos prontos do Firebird. Na sequência podemos acessar o diretório /usr/share/doc/firebird2.5-examples/examples/empbuild para descompactar o banco de exemplo denominado employee.fdb.gz. Depois de descomprimir o banco de exemplo é necessário alterar o proprietário para firebird:firebird e, por fim, vamos mover o arquivo para o diretório /var/lib/firebird/2.5/data/ onde normalmente ficam armazenadas as bases de dados do firebird em servidores Linux. 

root@Linux:/# apt-get install firebird2.5-examples firebird2.5-dev 
root@Linux:/(...)# cd /usr/share/doc/firebird2.5-examples/examples/empbuild/
root@Linux:/(...)# gunzip employee.fdb.gz
root@Linux:/(...)# chown firebird.firebird employee.fdb
root@Linux:/(...)# mv employee.fdb /var/lib/firebird/2.5/data/

Agora, além do servidor instalado e em execução, temos também um banco de dados (.fdb) localmente armazenado no servidor que pode ser acessado remotamente. Para testar se o banco de dados está funcionando através da rede, em qualquer estação cliente é possível instalar o gerenciador gráfico FlameRobin (http://www.flamerobin.org/). Seguindo o mesmo espírito do próprio Firebird, o FlameRobin é uma ferramenta open-source e gratuita, bastante leve e disponível para as mais diversas plataformas, seja Linux, Windows, Mac OS, FreeBSD ou Solaris. 

Façam seus testes...

Samuel.

quinta-feira, 15 de setembro de 2016

Configuração de Suporte a Multicast em Switches Catalyst

Olá Pessoal,

A maioria das aplicações existentes em uma rede de computadores segue o modelo de comunicação cliente/servidor, ou seja, através de uma comunicação unicast (de um para um) onde os pares envolvidos sempre são uma estação cliente e outra estação servidora. No entanto, também podem existir aplicações de natureza multicast com comunicação de um para muitos, por exemplo quando existe um servidor de origem responsável por gerar conteúdo de interesse de múltiplas estações clientes (não de todas). Alguns exemplos comuns de serviços de natureza multicast são: clusterização de servidores, treinamentos online via telepresença, soluções de vigilância com câmeras IP, ferramentas de monitoramento distribuído, aplicações multimídia (áudio/vídeo), etc...

Quando existe alguma aplicação de natureza multicast na empresa é necessário preparar a infraestutura de switches para lidar de maneira apropriada com esse tipo de tráfego para otimizar sua propagação, caso contrário os switches simplesmente irão encaminhar todo o tráfego de maneira broadcast para todas as suas interfaces, oferecendo desempenho ruim porque gera mais tráfego nos links da infraestrutura. Qualquer endereço desconhecido por um switch em sua tabela MAC que não possa ser propagado para um destinatário de maneira unicast (uma única interface) ou que não tenha sido configurado com o vínculo de portas em grupo para ser propagado de maneira multicast (múltiplas interfaces) faz com que a propagação do tráfego ocorra de maneira broadcast (para todas as interfaces).

Para exemplificar o procedimento de configuração do suporte a multicast nos switches Catalyst da Cisco, a figura abaixo ilustra um cenário com dois switches que fazem parte da infraestrutura de um ambiente qualquer. Nesse ambiente existe uma aplicação multicast originando conteúdo, além de 3 estações diretamente interessadas no consumo do conteúdo da aplicação servidora, ou seja, esse exemplo caracteriza uma comunicação multicast de um para muitos. 


Por padrão os switches Catalyst vem ativados com o recurso IGMP Snooping, o que permite que os grupos multicast sejam automaticamente detectados na rede através do protocolo IGMP, sem nenhuma configuração. No entanto, se não existir um roteador multicast que seja responsável por enviar queries IGMP na rede para indagar quais máquinas conectadas em quais portas dos switches têm interesse em formar um grupo multicast, então não é possível tirar proveito do recurso IGMP de maneira dinâmica sem nenhuma configuração nos switches da infraestrutura.

Obs.: Caso o leitor tenha interesse na configuração de um roteador multicast, recomendo a leitura de outros artigos no blog que abordam os protocolos PIM-DM e PIM-SM de roteamento multicast.

Nesse exemplo em que não existe um roteador multicast, há duas possíveis soluções para configurar os grupos multicast diretamente nos switches: (1) através do recurso IGMP Querier que é suportado apenas em alguns switches mais novos ou (2) através da configuração manual de quais portas representam um grupo para uma determinada aplicação.

A configuração do querier IGMP Querier nos switches é bastante simples:

Switch-A(config)# ip igmp snooping querier

Switch-B(config)# ip igmp snooping querier

Caso os switches não tenham suporte ao recurso anterior, a solução é fazer o mapeamento manual das interfaces que pertencem a um grupo multicast. É importante saber que no IPv4 todo tráfego destinado para o intervalo de endereços que varia de 224.0.0.0 até 239.255.255.255 (Classe D) representa um fluxo multicast, de forma que o endereço lógico da camada de rede é mapeado para um endereço físico da camada de enlace que é pré-definido pelo IEEE e tem o formato 01:00:5E:XX:XX:XX, sendo que o final representa os últimos 23 bits do endereço IPv4 (RFC 1112). Toda máquina que é origem de tráfego multicast encaminha seu conteúdo para um endereço IP multicast da Classe D que representa um grupo.

Obs.: É igualmente importante saber que no IPv6 os endereços iniciados em FF00::/8 representam um fluxo multicast, de forma que o endereço lógico da camada de rede é mapeado para um endereço físico da camada de enlace que é pré-definido pelo IEEE e tem o formato 33:33:XX:XX:XX:XX, sendo que o final representa os últimos 32 bits do endereço IPv6 (RFC 2464).

Essa lógica de agrupamento é implementada através das próprias aplicações servidora e cliente, ou seja, a aplicação servidora utilizará um endereço multicast para alcançar seus receptores, sendo que esse endereço pode estar fixado na lógica da aplicação ou pode ser configurado pelo usuário. Por sua vez, as aplicações clientes ingressam a máquina receptora no respectivo grupo multicast por meio da configuração automática de um endereço IP de multicast sem que o usuário tenha que fazer essa configuração de endereçamento indivualmente em cada máquina receptora. Dessa forma a máquina cliente passa a responder por 2 endereços IP, sendo um endereço unicast configurado pelo administrador (manualmente ou via DHCP) e outro endereço multicast automaticamente configurado pela aplicação cliente.

No exemplo proposto o endereço multicast utilizado pela aplicação servidora para alcançar os receptores é 239.239.239.239, de forma que o respectivo MAC multicast será 01:00:5E:6F:EF:EF. A configuração manual consiste em informar no switch da esquerda que as interfaces f0/1, f0/3 e g0/1, onde estão conectados dois receptores e um switch que possui outro receptor, devem ser associadas com o endereço MAC da aplicação multicast (01:00:5E:6F:EF:EF). Da mesma forma, no switch de direita basta informar que a interface f0/1 possui um receptor conectado e associá-la com o MAC da aplicação multicast. Os comandos necessários para realizar o mapeamento estático são listados abaixo:

Switch-A(config)# mac address-table static 0100.5e6f.efef vlan 1 interface g0/1 f0/1 f0/3

Switch-B(config)# mac address-table static 0100.5e6f.efef vlan 1 interface f0/1

Fica visível que o mapeamento manual das interfaces dos switches que pertencem a um determinado grupo multicast não é muito viável em ambientes grandes que possuem vários grupos multicast, ou seja, não é nada escalável. No entanto, se o ambiente é menor e não possui um roteador multicast ou se os switches não possuem suporte ao recurso querier do IGMP, então o mapeamento manual é a opção remanescente. 

Façam seus testes...

Samuel.