Interoperabilidade – Caso de Sucesso
Companhia Siderúrgica Nacional integra soluções open
source em ambiente Windows
Resumo
País: Brasil
Industria: Manufatura / Processos
• Companhia Siderúrgica
Nacional integra soluções
Open Source com plataforma
Microsoft
• Empresa com mais de 19.000
funcionários, utiliza a solução
de monitoração Open Source
Nagios integrada com
servidores Windows,
Exchange server, clusters de
servidores para aplicações de
missão crítica e banco de
dados SQL Server. Neste caso,
os responsáveis na CSN
descrevem como utilizaram
recursos de programação em
script do Windows para
realizar esta integração
• Integração de servidores DNS
utilizando BIND com o Active
Directory em uma resolução
de nomes integrada entre
diferentes zonas
A CSN – Companhia Siderúrgica Nacional, primeira produtora integrada de aço plano
no Brasil e uma das principais empresas do setor de siderurgia no país, integrou
soluções open source em ambiente Windows. Durante o processo de aquisição de uma
nova empresa, a área de TI da CSN precisou integrar a resolução de nomes de
servidores através de recursos existentes em servidores DNS baseados em Windows
e LINUX. Mais tarde, a área de TI da CSN, que utiliza o Nagios – ferramenta Open
Source para monitorar seus ativos de TI e gerar alertas de eventos configuráveis,
integrou os servidores Windows, Exchange, Active Directory e Clusters baseados em
tecnologia Microsoft dentro dessa solução, através de recursos nativos de scripting do
ambiente Windows. O software open source Nagios é a principal ferramenta de
monitoração de ativos da rede CSN. De forma simples, a empresa monitora toda a sua
rede Microsoft, utilizando ferramentas nativas do Windows e scripts desenvolvidos
pelos analistas CSN. Servidores Unix e outros dispositivos de rede como roteadores,
switches e appliances também entram na conta.
“Estamos monitorando todos os datacenters, incluindo das filiais e demais
controladas. Já são quase 1500 devices no console do Nagios, que roda em um
servidor dedicado Ubuntu Linux”, conta Marcus Vinícius, administrador de Sistemas
Operacionais da área de TI da CSN.
O analista de suporte explica que, para o ambiente Windows, a empresa desenvolveu
scripts em vbscript, powershell e até em batch files. Os scripts coletam informações
sobre espaço em disco utilizado, serviços e seus estados, os nós atuais dos grupos
Failover cluster, transações de webservices hospedados em IIS para aplicações críticas
e dados de performance de servidores, como as operações de I/O em disco.
Estes scripts verificam se as informações estão de acordo com os thresholds
estabelecidos pela CSN e determinam seu return code (ok, warning e citrical), além de
uma mensagem descritiva do problema. Todas estas informações são enviadas ao
Nagios, que as exibe de forma centralizada para a equipe de monitoração.
“Estamos monitorando filas SMTP e se as bases de caixas postais estão montadas
de nossos servidores Microsoft Exchange, através de vbscripts. O domínio do Active
Directory na CSN possui monitoração de replicação entre sites pelas ferramentas do
Interoperabilidade – Caso de Sucesso
AD, como repadmin, porém as informações são enviadas ao servidor do Nagios”,
detalha.
Para a integração entre os diferentes sistemas operacionais, a área de TI da CSN utiliza
os plugins do Nagios, o NRPE (Nagios Remote Plugin Executor) e NSCA (Nagios Service
Check Acceptor). O NRPE é responsável pela execução periódica dos scripts. Trata-se
de um serviço no Windows, que recebe os comandos do Nagios de acordo com o
schedule programado e que verifica se o resultado está de acordo. Pode funcionar
como um aviso temporário ou um alerta explícito se existe um problema crítico no
ambiente monitorado.
“Nossos servidores Microsoft SQL Server executam Jobs para os diversos sistemas de
negócio CSN e o resultado destes Jobs é enviado ao Nagios via NSCA, de forma passiva
– são enviados apenas no término da execução.”
Flávio Carelli, coordenador de TI da CSN, acrescenta: “A maneira pela qual essa
integração foi feita demonstra que o ambiente Windows possui mecanismos que
permitem, sem grande esforço, integrar diferentes plataformas dentro de uma mesma
proposta de solução que agrega valor aos processos de negócio.”
Carelli diz que existem várias formas de se aumentar a visibilidade e credibilidade do
ambiente de TI. “Encontramos no Nagios uma forma de interoperar com nossa rede,
que é primariamente Microsoft. Basta que os analistas responsáveis nos digam quais
são as necessidades e a partir daí, usamos a criatividade para o desenvolvimento,
sempre pensando no ganho da empresa na integração com o negócio, economia e
agilidade dos processos operacionais”, afirma Carelli.
Carelli assegura que não há outra forma de garantir a tão desejada interoperabilidade,
em qualquer contexto dentro dos heterogêneos ambientes de TI, sem que se passe por
uma discussão séria acerca de padrões abertos. Padrões esses que devem ser
respeitados por todos os fornecedores de software, de modo que a integração de
diversas implementações de um mesmo objeto seja possível. E nesse contexto, o
objeto pode ser um protocolo, documento, interface, aplicativo ou qualquer outro
elemento de um sistema de informação que espere receber chamadas de outro
componente ou que esteja disposto a invocar funcionalidades externas.
Sobre a resolução de nomes de servidores através de recursos existentes em
servidores DNS baseados em Windows e LINUX, Carelli explica que a rede da CSN
possui os servidores de nomes do Active Directory como sendo os name servers
padrões de todas as estações de trabalho. “Recentemente, nossa companhia adquiriu
uma nova empresa e minha equipe recebeu a missão de integrar essa nova rede da
maneira mais rápida possível e com a menor quantidade de mudanças num primeiro
Interoperabilidade – Caso de Sucesso
Para mais informações
Para mais informações sobre
ações de interoperabilidade
praticadas pela Microsoft e
pela comunidade de
desenvolvedores e usuários,
acesse nosso blog Porta 25 –
http://www.porta25.com.br
momento. A primeira questão era: uma vez conectadas as redes, como os usuários do
nosso lado poderiam acessar os sistemas hospedados na intranet da recém adquirida
empresa e como os seus novos usuários poderiam conectar-se a nossas aplicações de
forma transparente?”
O coordenador de TI explica que os servidores de DNS da nova empresa eram
baseados em LINUX, usando o servidor de DNS Open Source BIND, bastante difundido
e conhecido na Internet e na comunidade de softwares livres. Para permitir que
usuários em sua rede pudessem resolver também nomes de servidores da rede nova,
a empresa criou uma zona em seu servidor DNS do Active Directory do tipo stub. Na
configuração dessa zona é necessário apenas informar o endereço IP do servidor DNS
que é autoridade primária por este domínio. Este servidor (LINUX com BIND na rede
nova), precisou permitir que os servidores de nomes do Active Directory realizassem
transferências de zonas.
Carelli explica que a zona do tipo stub possui a seguinte característica: não é gerada a
cópia completa de toda a lista de nomes e endereços IP como em uma transferência
de zonas tradicional. Apenas os registros do tipo NS (name servers) são transferidos,
com seus respectivos endereços IPs (seus registros do tipo A), além do registro SOA.
“A partir dessa configuração, o servidor de nomes do Active Directory realiza uma
transferência de zona apenas com essas informações do servidor LINUX e passa a
realizar “iterative queries” para o servidor BIND quando recebe consultas para o
domínio da rede nova a partir de seus clientes. Nessa configuração que foi realizada,
quando o servidor de nomes do Active Directory recebe a resposta de uma consulta do
servidor BIND, esta fica armazenada em seu cache. Outros clientes que efetuem
consultas ao mesmo nome, já resolvido anteriormente, recebem a resposta
diretamente do cache do servidor do Active Directory”, detalha o executivo.
Esta configuração difere de um simples redirecionamento de consultas (conditional
forwarding, também possível entre servidores DNS Microsoft e BIND), pois há uma
transferência de zonas nesse caso. Qualquer alteração em registros NS ou SOA serão
refletidos na transferência, não sendo necessária uma alteração manual de um único
endereço IP para o qual o redirecionamento foi feito. Como não há também uma
transferência completa de zonas, como em um caso de delegação ou de criação de um
servidor de nomes secundário, o tráfego na rede é menor e não há o risco de
atualizações na zona principal provocarem cópias de registros entre servidores DNS.
Sobre a CSN
A CSN – Companhia Siderúrgica Nacional foi fundada em 9 de abril de 1941 e iniciou
suas operações em 1º de outubro de 1946. Como primeira produtora integrada de
aço plano no Brasil, a CSN é um marco no processo de industrialização do país. O seu
Interoperabilidade – Caso de Sucesso
aço viabilizou a implantação das primeiras indústrias nacionais, núcleo do atual
parque fabril brasileiro. Foi privatizada em 1993 e atualmente conta com a
capacidade de produção anual de 5,6 milhões de toneladas e cerca de dezenove mil
empregados. Concentra suas atividades em siderurgia, mineração e infraestrutura.
Atualmente, entre seus ativos a empresa conta com uma usina siderúrgica integrada,
seis unidades industriais, sendo três delas no exterior (Estados Unidos, Alemanha e
Portugal), minas de minério de ferro, calcário e dolomita, uma distribuidora de aços
planos, terminais portuários, participações em estradas de ferro e em duas usinas
hidrelétricas.
O aço da CSN está presente em diversos segmentos, entre os quais se destacam o
Automotivo, Construção Civil, Embalagem, Linha Branca e OEM, fornecidos para
clientes no Brasil e no exterior.