FAX
FOLHA DE MENSAGEM
COPEL
DESTINATÁRIO
DIVERSOS
FAX :
NÚMERO : STL/DGPT
056/2011
EMITENTE
STL/DGPT/VGCT
FAX : (41) 3331-3132
DATA : 11.10.2011
OBS:EM CASO DE PROBLEMAS NA RECEPÇÃO,FAVOR CHAMAR FAX (041)3331-3298 NÚM. DE PÁGS.=43 .
REF.:
OBJETO:
CHAMADA PÚBLICA COPEL STL 002/2011
Homologação prévia (pré-qualificação) de empresas que
apresentem proposta técnica para o fornecimento de uma solução
de infraestrutura de contingência dos sistemas e gerências
utilizados pela área de Telecomunicações.
ESCLARECIMENTO Nº 01
Através do presente, estamos procedendo aos seguintes esclarecimentos ao Edital
da Chamada Pública em epígrafe:
Pergunta 1:
Fornecer em cada site chassis com no mínimo 1536 GB de memória RAM DDR3
ECC em pentes de no mínimo 16 GB.
Questionamento:
Considerando 1536Gb solicitados, divididos em 32 blades com pentes de 16GB, a
quantidade por blade de memória, seriam 4 pentes de 16 somando 64GB de
Memória RAM por half-blade.
Da maneira que está escrito ficariam 48G RAM por blade que não seria possível
com pentes de 16G, pois ao configurar 2 processadores, a configuração da memória
deverá ser idênticos, portanto, deverá configurar um numero par de módulos de
memória. Ex: Quando configurado 2 processadores, temos que selecionar um
número par de pentes de memória (2/4/6/8/10.../). Para 48GB de Memória por Blade,
com pentes de 16GB, precisamos configurar 3x16GB e dessa forma não
conseguimos atender. Com pentes de 08GB, configuraríamos 6x8GB e
atenderíamos sem problemas.
Dessa forma, solicitamos a alteração de que cada blade suporte 64GB com pentes
de 16GB e que no total seja 2048GB por site chassi, ou; Trocar o pente de 16GB
para 08GB, para atendermos os 1536GB por site chassi e as blades com 48GB,
conforme pedido.
Resposta 1:
A solicitação não pode ser aceita. O proponente deverá atender os requisitos já
solicitados no edital.
Pergunta 2:
Fornecer cada blade com no mínimo 20Gbps full-duplex de troughput non-blocking
para conectividade com as demais infraestruturas.
Fornecer uplinks entre chassis e equipamentos de rede não inferior a seguinte
relação:
Uplink(s) = número de lâminas x 20 GBbps Full Duplex non-blocking.
Solicitamos a alteração para no minímo 10Gbps full-duplex de troughput nonblocking para que todos
os concorrentes estejam aptos a participar.
- Throughput mínimo de 10Gbps non-blockin,full duplex (solicitado 20Gbps).
Resposta 2:
A solicitação não pode ser aceita. O proponente deverá atender os requisitos já
solicitados no edital.
Pergunta 3:
“As fontes e ventiladores deverão ser entregues de acordo com a capacidade
máxima do gabinete, ou seja, devem ser provisionadas para a instalação e
configuração de 16 (dezesseis) lâminas de processamento, independente do
número total servidores ou gabinetes solicitados neste edital. As fontes devem ser
do tipo alta eficiência ou possuir eficiência de no mínimo 92%”.
“ Fornecer chassis com no mínimo 14 slots observando o fator de forma exigido,
sendo que estes serão orientados verticalmente,comportando as lâminas de
processamento”.
O Chassis do UCS suporta no máximo 8 Half Blades, ou 4 Full blades ( solicitado
numeros 16 e 14), conforme nosso entendimento abaixo:
Solicitamos retirar os pontos acima, pois não fica bem claro sobre a quantidade de
Blades por Chassi.
Resposta 3:
O edital exige para o bloco de infra-estrutura de contingência do tipo 1 e para o
fornecimento de chassis com orientação vertical no mínimo 14 slots e 8 blades de no
mínimo de meia altura, já para o fornecimento do item exclusivo de chassis, também
estaremos exigindo no mínimo 14 slots com o fornecimento inicial de 2 blades,
sendo todas no mínimo de meia altura.
A Copel poderá aceitar o fornecimento de blades com orientação horizontal desde
que cada chassis não ocupe mais do que 6 URs excluindo as infra-estuturas de
apoio (conexão) e deve ser tão ou mais eficiente (energia e refrigeração) quanto os
chassis de orientação vertical, neste caso a COPEL aceitará o fornecimento de
blades menores do que meia-altura, dado que a orientação de altura passa a ser
horizontal.
Para o caso do fornecimento horizontal, a Copel aceitará agrupamento de chassis
(item 4.1 e item 4.3. do edital) respeitando os números mínimos de 14 slots, sendo
permitindo neste caso o fornecimento de até 8 chassis por site (requisito do item
4.1.).
Devemos ressaltar que toda Blade deve respeitar os requisitos de performance e
banda, no caso de banda, o edital exige 20 Gbps por lâmina (blade com 2
processadores). Caso sejam fornecidas lâminas de altura inteira com 4
processadores, o troughput deverá ser de no mínimo 40Gbps por lâmina.
Pergunta 4:
Incluir Item para Gerenciamento das Blades:
Solicitamos incluir o texto abaixo para gerenciamento das blades, uma vez que não
está claro na RFI.
O gerenciamento de toda a solução deverá ser feito através de um ponto único e
central, com interface
Web, dotado das seguintes funcionalidades:
- Deve possuir ferramenta nativa para monitoração e gerenciamento de falhas de
todos os componentes da solução;
- Funcionalidade para automatizar a atualização e desatualização de todos os
firmwares e BIOS (Basic Input/Output System) de todas as blades e switches
presentes na solução;
- Deve suportar Role Based Access-Control (RBAC), para definição granular das
atribuições de cada administrador do sistema de gerenciamento;
- Suporte à abstração da identidade do hardware, através da criação de perfis de
servidores que mantenham informações pertinentes à identidade de hardware das
blades, que possam ser aplicados a qualquer blade, localizada em qualquer chassis
da solução, sem a necessidade de movimentação do perfil entre sistemas de
gerenciamento. Cada perfil de servidor deverá manter, no mínimo, as seguintes
configurações e identidades de hardware:
. Server UUID (Universally Unique Identifier);
. Configurações de Boot PXE;
. Número de vNICs;
. Associação de VLAN de cada interface de rede;
. Endereço MAC de cada interface de rede;
. WWPN (World Wide Port Name) da HBA;
. Parâmetros de Boot via Fibre Channel;
. Acesso Remoto:
A ferramenta de gerenciamento central deve oferecer a funcionalidade de acesso
remoto às console das blades, via browser, com as seguintes funções básicas:
. Boot e reboot remoto;
. Acesso a console gráfica do servidor, mesmo em falha de sistema operacional;
. Visualização de POST e BIOS, permitindo a configuração dos mesmos durante o
processo de boot;
. Acesso a dispositivos DVD e USB remotos;
- Configurar e monitorar pelo menos 300 (trezentos) blades, através da mesma
interface de gerência;
- Todos componentes de software e hardware do sistema de gerenciamento deverão
ser instalados de forma redundante, não sendo permitida a utilização de qualquer
blade da solução para inicialização e/ou operação do sistema de gerenciamento.
- O sistema de gerenciamento não pode possuir ponto único de falha, devendo
operar pelo menos em modo ativo-standby. Todas as licenças de software e suas
dependências como Sistema Operacional e SGBD devem ser fornecidas prevendo
este modelo.
Resposta 4:
A COPEL não realizará as inclusões solicitadas.
Pergunta 5:
4.1.3 Infra-estrutura de Armazenamento
Na página 11 – bullet 6 – é pedido a expansibilidade de 7.2 TB líquidos por gaveta.
Com uma gaveta cheia de discos de 600GB somente poderá ser atingido 7.2 TB
gross, ou seja, devido à formatação e paridades, teremos apenas 6.5 TB na gaveta
inteira e não 7.2 TB.
Acertar o texto para refletir esta realidade.
Resposta 5:
Será aceito o agrupamento de gavetas, desde que comprovadamente com igual
performance ou superior, para atendimento do requisito de capacidade liquida
exigida.
Pergunta 6:
No item 3.2 – página 1 – está descrito que:
“Garantir capacidade de ampliação por site para 228TB líquidos de estrutura de
armazenamento sem a necessidade de inclusão de controladoras adicionais na
infra-estrutura de storage”
Já no item 4.1.3 – página 12 – bullet 1 – descreve que pode ter inclusão de novas
controladoras “Garantir expansibilidade por site no bloco para no mínimo 228TB
líquidos e 380 discos com possibilidade de inclusão de controladoras.”
Acreditamos que o primeiro item esteja correto, ou seja, o storage deve atingir 228
TB líquidos SEM ADIÇÃO de controladora.
Acertar o item da página 12.
Resposta 6:
A ampliação por site para 228 líquidos e 380 discos com possibilidade de inclusão
de controladoras. A expansão para 114 TB líquidos sem a inclusão de controladoras.
Pergunta 7:
O que quer dizer com este item? Item 4.1.3 – Página 12 – bullet 5 “Fornecer
funcionalidade de desduplicação que apresente ganho comprovado em laboratório,
sem perda de performance em operações como de backup e restore. Em caso de
comprovação, o bloco básico de infra-estrutura de armazenamento poderá ser
fornecido com capacidade de expansão para até 86TB sem adição de
controladoras.”
Resposta 7:
Este requisito não é exigido no edital. Verificar o edital no site da COPEL.
Pergunta 8:
Item 4.1.3 – página 13 – bullets 2 e 3 O backup online referenciado nestes itens diz
respeito à cópia conhecida como “clone” efetuado com recursos do próprio storage,
está correto?
“Fornecer interface gráfica para controlar as operações de backup online, restore e
espelhamento de máquinas virtuais.
”Garantir o backup e restore com granularidade no nível de máquina virtual.”
Resposta 8:
O proponente deverá atender os requisitos já solicitados no edital. A terminologia
pode variar entre fornecedores.
Pergunta 9:
Item 4.1.3 – página 13 – bullet 5 “Fornecer recursos para clonar máquinas virtuais
(UPVs) utilizando as funcionalidade de clone do storage, podendo colocar essas
máquinas virtuais em diferentes datastores.”
O storage não consegue visualizar o conceito lógico de Datastore, mas sim apenas
LUNs (blocos).
É possível, através do clone, movimentar um datastore inteiro que encontra-se numa
determinada LUN, sem paradas no ambiente.
Para mover a UPV de um Datastore para outro, esta funcionalidade não pertence ao
storage, mas sim ao sistema de virtualização de UPVs – no nosso caso, o VMware.
Acertar a descrição do texto para refletir esta realidade.
Resposta 9:
A COPEL aceitará o fornecimento desta funcionalidade na solução de virtualização.
Pergunta 10:
Item 4.1.3 – página 13 – bullet 7 “Fornecer no mínimo 8GBytes de cache total para
as controladoras.”
Devido ao número inicial de UPVs (1000), achamos prudente aumentar o tamanho
mínimo de cache para 24 GB, pois apenas 8GB de cache no storage todo implica
que cada controladora usa apenas 4 GB Cache. Estes 4 GB cache ainda dividem-se
em Operações de Read, Operações de Write (que são espelhadas) e o sistema
operacional do storage.
Podemos chegar a um valor muito pequeno para Writes, podendo ser apenas 1 GB
para cada controladora, fazendo um “de/para” de 1000 UPVs para 1 GB cache, ou
seja, cada UPV ocuparia apenas 1 MB do cache.
Pensamos que seja prudente aumentar o valor do cache para 24 GB para não ter
nenhum problema na
fase de testes.
Resposta 10:
A COPEL aceitará o fornecimento de cache acima do solicitado no edital.
Pergunta 11:
Item 4.1.3 – página 13 – bullet 9 “Fornecer uma quantidade mínima de módulos que
garantam o bom desempenho da solução, utilizando como referência o acesso para
escrita e leitura das UPVs para até 114TB. Como referência, no caso do iSCSI ou
FCoE, no mínimo fornecer 6 portas 10Gbps. Sendo que para o FC o número deverá
ser equivalente.”
Aumentar o número de portas FC e FCoE/iSCSI para 8 x 4 GB ou 4 x 8GB no
mínimo, já que isto é pedido
no bullet 1 da página 14 do mesmo item, descrito abaixo:
“Possuir recursos de Fibre Channel que garantam, no mínimo, 4 (quatro) canais
Fibre Channel de 8Gbps, ou proporcionais em 4Gbps, suportando FC-AL/SW para
conexão a switches Fibre Channel e permitir conexão direta a servidores.”
Resposta 11:
A recomendação FC poderá ser aceita desde que atenda a equivalência de portas
10Gbps.
Pergunta 12:
4.2. Manutenção e Suporte para Bloco de Infra de Cont Tipo 1
- Entendemos que a Copel necessita de apenas uma carta do Fabricante onde
comprove que o Fabricante se compromete a fornecer peças, serviços e outros
subisidios necessários à manutenção dos equipamentos durante o período de
extensão de garantia. Sem que a Contratada forneça um valor para esse serviço pós
garantia. Está correto o nosso entendimento?
Resposta 12:
Não. Não está correto o entendimento. Neste item deve ser fornecido o serviço de
suporte e manutenção de acordo com os requisitos do edital.
Pergunta 13:
4.22.1 Facilidade de Virtualização 3
Entendemos que esta funcionalidade é feita na UPV, já que é uma verificação das
configurações dos servidores virtuais (compliance).
Pedimos para que seja a feita a mudança no texto para precificação por pacotes de
25 UPVs e não por processadores físicos.
Resposta 13:
Não podemos proceder tal alteração.
Pergunta 14:
4.3.1. Chassis “O chassis deve possuir fator de forma de 19 polegadas para racks
do tipo U, cuja finalidade exclusiva é a instalação de 16 (dezesseis) cartões do tipo
lâmina de servidores (blade servers) de meia altura, suportando no mínimo 8 (oito)
módulos de interconexão por gabinete, implementando módulos de passagem direta
de cabos ethernet gigabit ou fibre channel connectors ou módulos de switches
appliances de LAN, SAN, InfiniBand Networks ou dispositivos de conexão virtual.
Deve estar contemplado também um rigoroso controle térmico monitorado utilizando
arquitetura específica, combinando controle de consumo e regulação de energia
aliado à ventilação forçada ativa proporcionando um conjunto dinâmico
determinando menor impacto do ambiente de Datacenter no subsistema pretendido
e vice-versa.”
Sugerimos a retirada do item acima, pois não fica claro a quantidade exata de
instalação de Blade Servers por chassi. Ou sugerimos a alteração que o Chassi
suporte até 08 Blade Servers.
Resposta 14:
O edital exige para o bloco de infra-estrutura de contingência do tipo 1 e para o
fornecimento de chassis com orientação vertical no mínimo 14 slots e 8 blades de no
mínimo de meia altura, já para o fornecimento do item exclusivo de chassis, também
estaremos exigindo no mínimo 14 slots com o fornecimento inicial de 2 blades,
sendo todas no mínimo de meia altura.
A Copel poderá aceitar o fornecimento de blades com orientação horizontal desde
que cada chassis não ocupe mais do que 6 URs excluindo as infra-estuturas de
apoio (conexão) e deve ser tão ou mais eficiente (energia e refrigeração) quanto os
chassis de orientação vertical, neste caso a COPEL aceitará o fornecimento de
blades menores do que meia-altura, dado que a orientação de altura passa a ser
horizontal.
Para o caso do fornecimento horizontal, a Copel aceitará agrupamento de chassis
(item 4.1 e item 4.3. do edital) respeitando os números mínimos de 14 slots, sendo
permitindo neste caso o fornecimento de até 8 chassis por site (requisito do item
4.1.).
Devemos ressaltar que toda Blade deve respeitar os requisitos de performance e
banda, no caso de banda, o edital exige 20 Gbps por lâmina (blade com 2
processadores). Caso sejam fornecidas lâminas de altura inteira com 4
processadores, o troughput deverá ser de no mínimo 40Gbps por lâmina.
Pergunta 15:
“As fontes e ventiladores deverão ser entregues de acordo com a capacidade
máxima do gabinete, ou seja, devem ser provisionadas para a instalação e
configuração de 16 (dezesseis) lâminas de processamento, independente do
número total servidores ou gabinetes solicitados neste edital. As fontes devem ser
do tipo alta eficiência ou possuir eficiência de no mínimo 92%”. O mesmo
questionamento feito acima no item 4.1.1, Subitem 3.
Resposta 15:
Questionamento respondido na questão anterior.
Pergunta 16:
4.5.1. Lâminas para Chassis “Cada lâmina deve ser fornecida com no mínimo
20Gbps fullduplex de troughput nonblocking para conectividade com as demais infraestruturas.”
Solicitamos a alteração para no minímo 10Gbps full-duplex de troughput nonblocking para que todos os concorrentes estejam aptos a participar.
- Throughput mínimo de 10Gbps non-blockin,full duplex (solicitado 20Gbps).
Resposta 16:
Questionamento já respondido anteriormente.
Pergunta 17:
4.12.1 Switch Híbrido (UCS6100 , com funcionalidades diferentes do Nexus 5548,
este possui portas de interconexão enclosures e todo o sw de gerenciamento do
UCS incluso).
Fornecer 1 (um) switch híbrido.
Sugerimos 2x Switches Híbridos por site, para Alta disponibilidade da Solução.
Resposta 17:
O edital prevê a aquisição de até 4 switches hibridos além dos fornecidos na infraestrutura de contingência.
Pergunta 18:
Possuir no mínimo 48 (quarenta e oito) portas 10GBase-X. A Copel poderá utilizar
cada porta como acesso ou uplink.
Sugerimos que seja alterado o item acima para:
Suportar 40 Portas 10Gbps base-X Ethernet / FCoE + 12 Portas FC 1/2/4/8 Gbps
Resposta 18:
A COPEL não promoverá a alteração solicitada.
Pergunta 19:
Assegurar que a capacidade mínima da tabela de endereçamento MAC seja de 32k.
Sugerimos que seja alterado o item acima para:
Assegurar que a capacidade mínima da tabela de endereçamento MAC seja de 16k
Resposta 19:
A COPEL não promoverá a alteração solicitada.
Pergunta 20:
Garantir que capacidade mínima de VLANs (não considerar mecanismos
multiplicadores como por exemplo Q-in-Q) seja de 4094.
Sugerimos que seja alterada o item acima para:
Garantir que capacidade mínima de VLANs (não considerar mecanismos
multiplicadores como por
exemplo Q-in-Q) seja de 1024.
Resposta 20:
A COPEL não promoverá a alteração solicitada.
Pergunta 21:
Favor retirar os itens abaixo, pois a especificação do equipamento/funcionalidade
abaixo não é mais aplicado.
Retirar: (tal descrição pertence ao OTV existente no Nexus7000 somente)
Fornecer funcionalidades de L2 relacionados a Loop indesejado, como:
o A não necessidade de protocolos de controle L2 como BPDUs entre os sites,
isolando assim os domínios de falha;
o O não envio de MACs desconhecidos;
o O controle de loop de tráfego broadcast sem uso de STP;
o A funcionalidade de Multi Chassis Link Agregation ou Multi Chassis Etherchannel
entre switchs híbridos ou característica de virtualização que permita VSS ou recurso
simular;
o Extensão de VLANs entre os DCs, garantindo a não necessidade de protocolos de
controle L2 como BPDUs entre os sites, isolando assim os domínios de falha, além
de possuir recursos para controlar o envio de MAC desconhecidos e também
Implementar o controle de loop de tráfego broadcast;
Resposta 21:
A COPEL não promoverá a alteração solicitada.
Pergunta 22:
4.12.2. GERENCIAMENTO e SEGURANÇA
Retirar item 4.12.2 (itens de administração de switch, não aplicável ao 6100).
Resposta 22:
A COPEL não promoverá a alteração solicitada.
Pergunta 23:
4.16 Infra-estrutura de Serviços de DC tipo 1
Sugerimos especificar somente os ítens de FW / Sever Load Balance / Acesso
Seguro e Aceleração
individualmente.Os ítens Hw e Sistema operacional, colocados individualmente,
inviabiliza o uso de apliances no edital.
Resposta 23:
A COPEL não promoverá a alteração solicitada.
Pergunta 24:
4.16.2 Recursos de balanceamento
ACE Module
http://www.cisco.com/en/US/prod/collateral/modules/ps2706/ps6906/data_sheet_c78
_632383.html
Performance:
Implementar as seguintes características de Camada 7 (L7):
o Suportar no mínimo 20 Gbps de tráfego em camada 4;
o Suportar no mínimo 20 Gbps de tráfego de Camada 7;
Sugerimos a alteração para suportar no mínimo 16Gbps em camada 4 e camada 7.
Resposta 24:
A COPEL não promoverá a alteração solicitada.
Pergunta 25:
Suportar no mínimo 600k requisições por segundo na Camada 7;
Sugerimos a alteração para suportar no mínimo 200k requisições por segundo na
Camada 7.
Resposta 25:
A COPEL não promoverá a alteração solicitada.
Pergunta 26:
Suportar no mínimo 48 Milhões de conexões concorrentes;
Sugerimos a alteração para suportar no mínimo 4 Milhões de conexões concorrentes
Resposta 26:
A COPEL não promoverá a alteração solicitada.
Pergunta 27:
Métodos de Monitoramento:
O equipamento oferecido deverá suportar os seguintes métodos de monitoramento
dos servidores reais:
o Layer 3 – ICMP
o Conexões TCP e UDP pela respectiva porta no servidor
o Layer 7 – Conexões específicas ao protocolo de aplicação.
Neste caso, ao menos HTTP, HTTPS, FTP, SASP, RADIUS,
SMTP, MSSQL, ORACLE, RPC, LDAP, IMAP, NNTP, POP3,
SIP, Real Server, SOAP, SNMP e WMI deverão ser suportados. A Copel aceitará e
deverá aprovar previamente o uso de script para alguns dos protocolos
supracitados.
NAO suportados: MSQL, ORACLE , RPC e SOAP
Resposta 27:
A Copel aceitará desde que aprovado previamente o uso de script para alguns dos
protocolos supracitados.
Pergunta 28:
Sugerimos acrescentar os itens abaixo:
Suporte a 250 Contextos virtuais, para melhor segmentação dos Clientes dentro do
DC Fonte redundante 4x Interfaces 10 Gbps para interconexão com infra do DC
Atual da Copel.
Resposta 28:
A COPEL não promoverá a alteração solicitada.
Pergunta 29:
4.16.3. Recursos de Segurança 4.16.4. Firewall de Aplicação
Solicitamos os seguintes esclarecimentos sobre o item acima:
Quantas aplicações serão monitoradas? Distribuidas em quantos servidores
físicos?
Qual o Throughput de dados para Web (Mbps/Gbps)?
Quantas transações HTTP por segundo deverão ser monitoradas em média?
Faremos análise SSL? Quantas Transações SSL por segundo por website?
Qual o tamanho das chaves? (1024 ou 2048)
Realizaremos checagem de dados de saída (DLP – Data Loss Prevention)?
Qual o método de deployment: Proxy (reverso/transparente), Inline/Bridge ou
Sniffing?
Quantos segmentos fazem parte do escopo?
Necessário HA (alta disponibilidade)? Ativo/Ativo ou Ativo/Passivo?
Trabalharemos com Disaster Recovery (Sites Redundantes)?
Uma segunda opção para que possamos atender e que para a arquiterura de
segurança ficar robusta, sugerimos a alteração do texto de Firewall de Aplicação
para o uso de IPS, conforme texto abaixo, pois para uma estrutura de Data Center
mais segura, entendemos que uma solução baseada em IPS + Firewall atende
melhor a um Firewall de Aplicação. Abaixo, seguem as sugestões de texto.
Resposta 29:
Detalhes de cada solução serão discutidos a partir da avaliação da documentação
da arquitetura que será proposta e do caderno de testes. Cada proponente deverá
seguir os requisitos mínimos exigidos no edital.
Pergunta 30:
1. IPS
Informações diretamente relacionadas ao modelo do appliance
A solução oferecida deve ser contemplada em tecnologia “Appliance”.
Deve ser fornecido com pelo menos 02 interfaces de monitorização 10Gbps
autosensing.
Deve ser fornecido com uma interface dedicada para gerenciamento (10/100 ou
10/100/1000 autosensing).
Deve permitir montagem em rack de 19 polegadas.
Deve ser fornecido com fontes de alimentação elétrica redundantes, internas ao
equipamento.
Deve suportar 802.1q e a capacidade de encaminhar tráfego em até 255 pares de
VLANs em cada interface de monitoração.
Deve possuir performance mínima de detecção de invasões de 4 Gbps,
considerando-se todas as assinaturas disponíveis carregadas.
Informações para todos os modelos
O sistema de detecção de intrusão deve ser composto por dois elementos : sensor
(“probe”) e console de gerenciamento. A probe deverá ser responsável por monitorar
a rede a que está conectada, analisando tanto o cabeçalho(header) como a área de
dados (payload) de cada pacote que trafega pela rede citada, de modo a verificar se
os referidos pacotes constituem tráfego autorizado.
A console de gerenciamento deverá permitir a configuração gráfica dos sensores
(“probes”) e receber os alertas e notificações de ataques de todos os sensores que
monitoram a rede.
Toda a comunicação entre o sensor e a console de gerenciamento deve ser
criptografada.
Funcionalidade para detectar ataques em tempo real.
Deve suportar operação em modo promíscuo (IDS).
Deve suportar operação em modo “in-line” (IPS), descartando pacotes
identificados como associados a ataques. Deve ser possível a seleção, por interface,
do modo de operação desejado (IPS in-line/IDS). Deve ser possível operar
simultaneamente como IPS e IDS.
Capacidade de detecção de intrusões e ataques no segmento de rede que está
monitorando e analisando.
Deve ser capaz de monitorar o tráfego de redes TCP/IP, incluindo : redes locais,
conexões Internet e conexões discadas.
Deve analisar cada um dos pacotes que trafegam pela rede a que está conectado
e também a relação de tais pacotes com os adjacentes a ele no fluxo de dados da
rede (análise de contexto). Imediatamente após a identificação de uma eventual
violação da política de segurança o sensor deve enviar um alarme para o software
de controle.
Deverá ter uma base de assinaturas com descrição da utilização de cada uma
delas e tipos de ataques detectados. A solução deverá incluir o acesso a atualização
de assinaturas em caso de detecção de novas vulnerabilidades.
O equipamento deve ser constantemente atualizado com informações sobre
dispositivos com má reputação na Internet, ou seja, dispositivos reconhecidos pela
participação em atividades maliciosas. A informação sobre a reputação da origem do
pacote deve ser utilizada na análise do tráfego, reduzindo a ocorrência de falsos
positivos no descarte de pacotes.
Deve suportar a modificação de assinaturas, isto é, permitir a edição de
assinaturas existentes na base de dados, ajustando-se ao perfil de tráfego de rede.
Deve suportar a criação de assinaturas, isto é, permitir que se possam criar novas
assinaturas e anexá-las à base de dados existente, adaptando-se as reais
necessidades de tráfego de rede (na criação das novas assinaturas deve ser
permitida a utilização de parâmetros de nível 2 a nível 7 do modelo OSI).
Deve ser possível criar assinaturas do tipo “string-match” e associá-las a qualquer
porta TCP para verificação da ocorrência de conjunto de caracteres definidos pelo
administrador de política de segurança no conteúdo dos pacotes IP que trafegam
pela rede.
O software de controle deve ser capaz de enviar alarmes para um sistema de
pager ou via e-mail para notificar a violação de uma dada regra de segurança.
O sistema deve registrar informações tais como origem, destino, horário e tipo dos
ataques ocorridos.
Deve suportar “Protocol Anomaly Detection” como método de análise de tráfego.
Deve suportar verificação de adequação dos protocolos que trafegam na rede às
definições destes constantes nas RFCs (análise de “RFC compliance”).
Deve suportar análise “stateful” de pacotes para garantir maior acuracidade de
detecção (“Stateful Pattern Matching”).
Deve suportar detecção de anomalias de tráfego da Rede (anomalias associadas
a definições estatísticas de tráfego).
Deve detectar ataques associados a protocolos que não estejam usando as portas
canônicas de serviço (portas padrão reservadas para os protocolos de aplicação).
Deve promover reordenação e remontagem de fragmentos IP antes de efetuar
análise.
Deve possuir estrutura de “normalização” de tráfego para que possam combater
as técnicas de evasão.
O sistema deve permitir a detecção das seguintes classes de ataques: o ataques
com nomes específicos: tais como PHF e Smurf; o ataques genéricos: (ataques
nomeados com múltiplas variações) tais como Pacotes IP fragmentados, Teardrop,
Land, Ping Sweep, Port Sweep (UDP e TCP), “Remote Shell Code”; os ataques com
assinaturas complexas: tais como Simplex-Mode TCP hijacking , Email Spam,
BackOriffice 2000 StealthMode, Unicode Decodes, IIS Unicode exploit, cross-site
scripting, directory traversal, command injection, SQL Injection, Header Spoofing; o
Port Scanning (“Full connect”, “SYN Stealth”, “FIN Stealth”, UDP); o Detecção de
tráfego de pelo menos os seguintes protocolos “peer-to-peer” (kazaa, gnutella, qtella,
bearshare, gnucleus, limewire, morpheus, mutella, hotline, edonkey, soulseek,
napster, bittorrent); o Detecção de tráfego de pelo menos os seguintes sistemas de
“instant messaging” (yahoo messenger, ICQ, AOL, MSN); o Internet Worms : o
sistema deve ser capaz de detectar pelo menos os seguintes vírus de rede : CodeRed CRv1, Code-Red CRv2, Code-Red II, Nimda, Bagle; o Ataques de DoS (Denialof –Service) direcionados à rede IP; o O sistema deve permitir a criação de regras
personalizadas de identificação de invasões para que possa ser adaptado à
estrutura particular disponível na DPF (no próprio sistema devem ser
disponibilizados recursos para que se criem assinaturas de ataques personalizadas
usando-se atributos dos níveis 2 até 7 do modelo de referência OSI) .
Além da geração de alarmes em caso de detecção de tentativa de ataque, o
sistema deve ser capaz de reagir em tempo real a uma tal tentativa. As reações
devem ser configuradas por assinatura e, no mínimo as duas seguintes modalidades
devem ser suportadas: o “Blocking”/“Shunning” – reconfiguração automática
(realizada pelo sensor) daslistas de acesso do firewall fornecido, de modo a
bloquear o endereço IP originador do ataque ( o período de bloqueio deve ser
configurável pelo administrador do sistema); o “TCP Reset” – em caso de ataque
utilizando protocolo TCP, o sensor deve ser capaz de promover um “reset” nas
portas TCP de origem e/ou destino associadas àquela conexão.
Quando da operação em modo “in-line”(IPS) devem ser suportados no mínimo os
seguintes tipos de reação (configuráveis por assinatura de ataque) : geração de
alerta, gerar trap SNMP, fazer “logging”dos pacotes gerados pelo sistema “vítima”,
fazer “logging” dos pacotes gerados pelo sistema que está efetuando o ataque,
promover “reset” da conexão TCP, bloquear o pedido de conexão, bloquear o
endereço que está gerando o ataque de conexão, negar pacotes associados ao
ataque “in-line”.
O sistema deve suportar “logging” de sessão via IP (“IP session logging”). Os logs
devem ser compatíveis com o formato “TCPDump”.
Deve possuir opção de gravação de sessões completas para servir como subsídio
para análise forense (IP Session Logging). Estes dados devem ficar armazenados
em arquivos no sensor e ser visualizáveis através da console de gerência. Estes
arquivos devem ser protegidos por controle de acesso.
Deve suportar filtragem de assinaturas por endereço IP de origem/destino
(possibilidade de definir que uma dada assinatura de ataque deverá ser disparada
somente quando estiver associada a endereços IP origem/destino específicos).
Implementar NTP (Network Time Protocol), conforme RFC 1305, contemplando
autenticação MD5 entre os peers.
Capacidade de gerar relatórios personalizados, por sensor, por horário, por
evento, por endereço, por porta.
Permitir a configuração do Sensor através de linha de comando (CLI) e HTTPS.
O sistema deve registrar informações tais como origem, destino, horário e tipo dos
ataques ocorridos.
1. Stateful Firewall com suporte a VPN
Características Básicas
1. Equipamento do tipo “appliance”, dedicado à terminação de túneis IPSEC e com
suporte à terminação de conexões SSL-VPN.
2. Deve ser montável em rack de 19 polegadas (devem ser fornecidos os kits de
fixação necessários).
3. Deve ser fornecido com fontes redundantes internas ao equipamento.
4. Deve ser fornecido com pelo menos 08 interfaces 10/100/1000 auto-sense e 04
(quatro) interfaces 10Gigabit Ethernet. Os adaptadores para as portas
10GigabitEthernet devem ser do tipo SFP+ com padrão SR.
5. Deve suportar o acréscimo de pelo menos 06 interfaces Gigabit Ethernet
6. Deve suportar o acréscimo de pelo menos 04 interfaces 10Gigabit Ethernet
(10GE).
7. Deve suportar agregação de portas GigabitEthernet e 10GigabitEthernet. Deve
ser possível formar grupos de até 08 portas GigabitEthernet e 04 portas
10GigabitEthernet.
8. Deve suportar funcionalidade de Stateful Firewall com performance mímina de 20
Gbps e mínimo de 4 milhões de conexões simultâneas.
9. Deve suportar a criação de pelo menos 200.000 (duzentas mil) novas conexões
por segundo e encaminhamento de pelo menos 4 milhões de pacotes por segundo.
10. Não deve haver restrição de número de usuários simultâneos através do
equipamento para a licença de software fornecida para a funcionalidade de Stateful
Firewall.
11. Deve suportar a definição de VLAN trunking conforme padrão IEEE 802.1q.
Deve ser possível criar pelo menos 250 interfaces lógicas associadas a VLANs e
estabelecer regras de filtragem (Stateful Firewall) entre estas;
12. Deve construir registro de fluxos de dados relativos a cada sessão iniciada,
armazenando para cada uma destas sessões informações tais como endereços de
origem e destino dos pacotes, portas TCP (e UDP) de origem e destino, bem como
números de seqüência dos pacotes TCP, status dos flags “ACK”, “SYN” e “FIN”.
13. O equipamento deve permitir a “randomização” do número de seqüência TCP,
ou seja, funcionar como um “proxy” de número de seqüência TCP de modo a
garantir que um host situado em uma interface considerada “externa” (insegura), sob
o ponto de vista de política de segurança do firewall, nunca tenha acesso ao número
de seqüência TCP real do host seguro (interno ao firewall) em uma sessão
estabelecida entre os referidos hosts;
14. Possibilitar o registro de toda a comunicação realizada através do firewall e de
todas as tentativas de abertura de sessões e conexões que por ele forem recusadas.
15. Deve suportar agrupamento lógico de objetos (“object grouping”) para criação de
regras de filtragem. Deve ser possível criar grupos de pelo menos os seguintes tipos
de objetos: hosts, redes IP, serviços. Deve ser possível verificar a utilização (“hit
counts”) de cada regra de filtragem (“Access Control Entry”) individualmente,
independentemente do fato de a configuração da política ter utilizado o conceito de
agrupamento lógico de objetos.
16. A solução fornecida deve possuir a funcionalidade de “proxy” de autenticação (
“authentication proxy”), permitindo a criação de políticas de segurança de forma
dinâmica, com autenticação e autorização do acesso aos serviços de rede sendo
efetuadas por usuário. Deve ser possível obter as informações de usuário/senha por
meio de pelo menos os seguintes protocolos : HTTP, HTTPS e Telnet. Deve ser
possível ao Firewall exigir autenticação inclusive para uso de protocolos que não
possuam nativamente recursos de autenticação.
17. Deve suportar autenticação usando base local de usuários (interna ao
equipamento).
18. Implementar políticas de controle de acesso baseadas em informações de
horário (“time-based access control”)
19. Deve implementar remontagem virtual de fragmentos (“Virtual Fragment
Reassembly”) em conjunto com o processo de inspeção stateful. Deve ser possível
estabelecer o número máximo de fragmentos por pacotes e timeouts de
remontagem.
20. Possuir suporte a inspeção “stateful” para pelo menos os seguintes protocolos
de aplicação: Oracle SQL*Net Access, Remote Shell, FTP, HTTP, SMTP, ILS
(Internet Locator Service), LDAP, ESMTP, TFTP.
21. Possuir suporte a inspeção stateful dos protocolos de sinalização de telefonia
H.323(v1,v2,v3,v4), SIP (Session Initiation Protocol), MGCP e SCCP. A partir da
inspeção dos protocolo de sinalização o firewall deve criar dinamicamente as
permissões pertinentes para o tráfego de mídia (RTP/RTCP) entre os telefones
envolvidos.
22. Possuir capacidade de limitar o número de conexões TCP simultâneas para
cada IP de origem (sem necessidade de especificar tal endereço IP).
23. Possuir capacidade de limitar o número de conexões TCP incompletas (‘halfopen’) simultâneas para cada IP de origem (sem necessidade de especificar tal
endereço IP).
24. Possuir capacidade de limitar o número de conexões TCP simultâneas para um
endereço de destino especificado.
25. Possuir capacidade de limitar o número de conexões TCP incompletas (‘halfopen’) simultâneas para um endereço de destino especificado.
26. Deve permitir simultaneamente com a implementação “Network Address
Translation” a filtragem “stateful” de pelo menos as seguintes aplicações:
H.323 (v1,v2, v3,v4) , Real Time Streaming Protocol (RTSP), SIP (Session
Initiation Protocol), MGCP (Media Gateway Control Protocol)
Microsoft Networking client and server communication (NetBIOS over IP)
Oracle SQL*Net client and server communication;
Domain Name System (DNS)
SUN Remote Procedure Call (RPC);
File Transfer Protocol (FTP) – modos “standard” e “passive”
27. O equipamento deve permitir a inspeção detalhada de conexões HTTP,
contemplando, no mínimo, as seguintes funcionalidades:
Verificação de conformidade das requisições HTTP com a RFC 2616 e suporte a
bloqueio de requisições não conformes
Verificação do comprimento do “Header” das mensagens HTTP (requisições dos
clientes e respostas dos servidores). Deve ser possível bloquear conexões cujos
comprimentos do Header HTTP não estejam em conformidade com os valores prédefinidos na política de Segurança aplicada ao equipamento.
Possibilidade de bloqueio de requisições cujo comprimento do URI não esteja
dentro dos limites pré-definidos pela Política de Segurança aplicada ao
equipamento.
Possibilidade de bloqueio de requisições cujo comprimento da parte de dados do
HTTP (“content-length”) não esteja dentro dos limites pré-definidos pela Política de
Segurança aplicada ao equipamento.
Possibilidade de bloqueio de conexões HTTP de acordo com o tipo de conteúdo
por elas transportado. O equipamento deve prover suporte a filtragem de no mínimo
os seguintes tipos de conteúdo: audio/mpeg, audio/x-ogg, audio/x-adpcm, audio/xwav , image/jpeg, image/x-3ds, image/portable-bitmap, image/cgf, image/png,
image/x-bitmap, image/xportable- greymap, image/gif, , video/-flc, video/sgi, video/xmng, video/mpeg, video/x-avi, video/x-msvideo, video/quicktime, video/x-fli,
video/x-niff, video/tiff , application/zip, application/x-gzip, application/postscript
Possibilidade de bloqueio de requisições HTTP de acordo do método
(“request method”) utilizado pelo cliente web.
Deve possuir capacidade de filtrar “applets” Java e controles ActiveX.
28. O equipamento deve permitir a inspeção detalhada de conexões FTP,
contemplando, no mínimo, as seguintes funcionalidades:
Permitir o bloqueio seletivo de comandos utilizados em requisições FTP
(“request commands”).
Verificar se os comandos “PORT” e “PASV” foram truncados, permitindo o
“reset” da sessão TCP caso isto tenha ocorrido.
Garantir que o comando “PORT” só ocorra na parte cliente da conexão FTP,
sendo possível promover o “reset” da sessão TCP caso tal comando seja detectado
em uma mensagem enviada por um servidor FTP.
Garantir que o comando “PASV” só ocorra na parte servidor da conexão FTP,
sendo possível promover o “reset” da sessão TCP caso tal comando seja detectado
em uma mensagem enviada por um cliente FTP.
Verificar a negociação de portas TCP a serem usadas na conexão, permitindo
a finalização da sessão TCP caso uma porta entre 1 e 1024 tenha sido negociada.
Permitir a substituição da resposta enviada pelo servidor FTP a um comando
“SYST” para evitar que o “system-type” do servidor seja revelado aos clientes.
29. Possuir suporte a tecnologia de Firewall Virtual, sendo fornecido com pelo
menos 20 (vinte) instâncias totalmente isoladas entre si. Dentro de cada instância de
Firewall deve ser possível definir regras independentes de filtragem, regras de NAT,
rotas e VLANs alocadas.
Dentro de cada instância de Firewall deve ser possível alocar no mínimo os
seguintes tipos de recursos : número conexões simultâneas, número de endereços
IP traduzidos, número de sessões de gerenciamento simultâneas, número de
endereços MAC.
Dentro de cada instância de Firewall deve ser possível limitar (promover “rate
limiting”) os seguintes recursos : taxa de estabelecimento de novas conexões, taxa
de inspeção de aplicações, taxa de transmissão de mensagens Syslog.
A exaustão dos recursos alocados para uma dada instância de Firewall não deve
ter influência sobre a operação das demais instâncias.
Deve suportar a adição de novas instâncias virtuais através de licenças de
software. Devem ser suportadas pelo menos 100 instâncias virtuais de
Firewall. Suporte a VPN
30. A solução deve suportar a terminação de pelo menos 4.000 (quatro mil) túneis
de IPSEC
VPN simultaneamente. Devem ser fornecidas licenças de Cliente IPSEC VPN para
pelo menos 5.000 usuários.
31. Deve haver versões do cliente IPSEC VPN fornecido com o concentrador para,
no mínimo, os seguintes sistemas operacionais: Windows XP, Windows Vista,
Windows 7 e Linux (Intel).
32. A solução deve suportar a terminação de pelo menos 2.000 (dois mil) sessões
SSL-VPN simultanemante.
33. Deve ser suportada a terminação simultânea de túneis IPSEC e SSL-VPN, de
modo que se suporte um total de pelo menos 6.000 (seis) mil usuários VPN.
Caso a solução não suporte todas as especificações de VPN (SSL e IPSEC) em um
único chassis, poderá ser fornecido um concentrador VPN externo, do mesmo
fabricante do firewall, desde que conectado a este através de pelo menos 02
interfaces 10Gbps. Tais interfaces 10Gbps deverão ser diferentes daquelas
originalmente especificadas para o firewall
34. Deve ser possível ao concentrador terminar túneis IPSEC do tipo “site-to-site”
(LAN-to- LAN)
35. O concentrador VPN deve suportar a terminação simultânea de conexões IPSEC
VPN e SSL VPN.
36. Suporte à criação de VPNs IPSEC com criptografia 168-bit 3DES, 128-bit AES e
256-bit AES. Deve possuir desempenho de no mínimo 2 Gbps para tratamento de
conexões IPSEC (padrões AES e 3DES). A criptografia deve ser realizada em
hardware dedicado.
37. Deve ser possível ao concentrador fornecido operar em modo “cluster”. O líder
do “cluster” deve ser responsável por direcionar conexões para os demais membros
do “cluster”.
38. Suportar alta disponibilidade das conexões IPSEC VPN, permitindo a utilização
de uma segunda unidade em “standby”. Em caso de falha de uma das unidades, não
deverá haver perda das conexões ativas (stateful failover) e a transição destas
conexões entre as duas unidades deve ser completamente transparente para o
usuário final.
39. Deve suportar negociação de túneis VPN IPSEC utilizando o protocolo IKE
(Internet Key Exchange) nas versões 1 e 2, para garantir a geração segura das
chaves de criptografia simétrica.
40. Suporte à integração com servidores RADIUS para tarefa de autenticação,
autorização e accounting (AAA) dos usuários que ganharam acesso via conexão
VPN (“Extended Authentication”)
41. O concentrador VPN deve ser capaz de passar pelo menos os seguintes
parâmetros para o cliente: endereço IP do cliente VPN, endereço IP do WINS
Server, endereço IP do DNS Server e Default Domain Name. A configuração do
cliente VPN deve ser completamente automatizada, sendo exigida do usuário
apenas a instalação do cliente VPN em seu PC.
42. O concentrador de VPN deve ser capaz de configurar nos VPN clients uma lista
de acesso de “split tunneling”, de modo a explicitar quais as redes podem continuar
sendo acessíveis de forma direta (sem IPSEC) durante uma conexão VPN à rede
corporativa. Deve também ser possível a operação no modo “all tunneling”, em que
todo o tráfego do VPN client só poderá ser transportado através da conexão
protegida.
43. O concentrador deve permitir a criação de “banners” personalizados para indicar
se houve sucesso ou falha na requisição de acesso VPN e, em caso de sucesso,
mensagens de natureza administrativa.
44. O concentrador VPN deve permitir a criação de base de usuários e grupos de
usuários que compartilham a mesma política de segurança de forma interna ao
equipamento.
45. O concentrador deve permitir a criação de pools de endereços IP de VPN
(endereços privados) internamente ao equipamento.
46. O concentrador VPN deve se integrar com servidores RADIUS para que estes
façam a atribuição dos endereços IP de VPN (endereços privados) aos clientes .
47. O concentrador deve permitir que os endereços IP de VPN (endereços privados)
sejam obtidos a partir de um servidor DHCP especificado pelo administrador do
sistema.
48. Deve ser possível a associação de diferentes pools de endereços IP aos
diferentes grupos de usuários que solicitarem conexão ao concentrador VPN.
49. O concentrador deve permitir a definição dos horários do dia e dos dias da
semana em que um dado usuário pode requisitar uma conexão VPN.
50. O concentrador VPN deve suportar NAT (Network Address Translation)
51. O concentrador VPN deve suportar operação no modo transparente a NAT
(“NATtransparent mode”), permitindo a utilização dos clientes VPN em ambientes
em que já se efetue PAT (Port Address Translation)
52. O concentrador VPN deve permitir a terminação de conexões no modo IPSEC
over TCP.
53. O concentrador VPN deve permitir a terminação de conexões no modo IPSEC
over UDP
54. Deve ser possível visualizar no concentrador o número de conexões VPN
estabelecidas em um dado instante e os respectivos usuários que estão fazendo uso
destas.
55. Deve ser posível visualizar no cliente VPN o endereço privado adquirido durante
a negociação da conexão IPSEC.
56. Deve ser possível definir vários templates de conexão no cliente VPN antes que
seja enviado para instalação no computador do usuário final. Estes templates devem
conter o endereço IP ou nome DNS associado ao concentrador e parâmetros
definidores das Security Associations (SAs) a serem usadas nas fases 1 (IKE) e 2
(IPSEC) de negociação dos túneis, incluindo algoritmo de criptografia (DES,
3DES,AES), algoritmo de hash (MD5, SHA), grupo Diffie-Hellman (1, 2, 5 e 7) e
tempo de duração (“lifetime”) da conexão. A configuração destes parâmetros deve
ser totalmente transparente para o usuário do VPN client.
57. Deve suportar a utilização de certificados digitais padrão X.509 para o próprio
concentrador VPN, possuindo integração com pelo menos as seguintes Certificate
Authorities (CAs) : Baltimore, Entrust, Verisign, Microsoft e RSA. Os clientes VPNs
devem ter o mesmo suporte a certificados digitais. Deve ser suportado o protocolo
SCEP para “enrollment” automático na autoridade certificadora (tanto para o
concentrador como para os clientes IPSEC).
58. O concentrador VPN deve suportar protocolo Syslog para geração de logs de
sistema.
59. Para SSL VPN devem ser suportadas no mínimo as seguintes aplicações
transportadas sobre conexões SSL para o concentrador : HTTP, POP3S, IMAP4S,
SMTPS.
60. Para SSL VPN devem ser suportados, via “Port Forwarding”, no mínimo as
seguintes aplicações: Telnet, SSH, FTP over SSH, Windows Terminal Services,
Outlook/Outlook Express e Lotus Notes.
61. Deve ser possível criar diferentes grupos de usuários SSL VPN, com definição
por grupo, do tipo de serviço permitido sobre as conexões SSL para o concentrador
(WEB, e-mail, sistemas de arquivos).
62. Deve ser possível especificar as URLs acessíveis através de conexões SSL
VPN.
63. Deve ser possível a criação de portal customizado para acesso SSL VPN. O
portal deve refletir os recursos disponíveis (aplicações e URLs acessíveis,
possibilidade de download do cliente SSL VPN, "banner de acesso") para o grupo a
que o usuário que requisita acesso pertence.
64. Deve ser possível acesso SSL-VPN a pelo menos os seguintes aplicativos
(Telnet, SSH, VNC, RDP e Citrix) sem necessidade de software cliente na máquina
remota. O acesso será viabilizado através de “plug-ins” para browsers.
65. Deve suportar autenticação SSL-VPN através de teclado virtual apresentado ao
usuário.
66. Deve implementar protocolo DTLS (TLS over UDP) de acordo com a RFC 4748
67. Deve ser possível realizar verificação de parâmetros na máquina do usuário
antes da apresentação das credenciais de identificação ("pre-login") . Deverá ser
possível verificar pelo menos os seguintes atributos: Chaves de Registro, Arquivos,
Endereços IP, Versão do Sistema Operacional e Certificados Digitais.
68. Deve ser possível a criação de regras para verificação da conformidade da
máquina com a política de segurança. Dever ser possível verificar no mínimo os
seguintes elementos: a instalação, habilitação e atualização do software antivírus e
anti-spyware e existência de personal firewall habilitado.
69. Deve ser possível estabelecer, por grupo, os serviços de acesso remoto
disponíveis para os usuários deste: IPSEC VPN, SSL-VPN (com cliente), SSL-VPN
(sem cliente) e qualquer combinação destes métodos.
70. Deve ser possível definir no concentrador VPN o mapeamento de atributos
LDAP e RADIUS para parâmetros existentes na configuração local de grupos do
concentrador.
Deve ser possível escolher, para cada grupo, se os parâmetros usados serão os
definidos localmente ou os mapeados de um grupo externo LDAP/RADIUS.
71. Deve implementar funcionalidade de Desktop Seguro Virtual em partição
criptografada isolada com no mínimo as seguintes funcionaliades :
o download do desktop seguro virtual deve ser feito de forma automática quando
da tentativa de estabelecimento da sessão SSL-VPN
Proteção contra KeyLoggers e ScreenLoggers
Bloqueio da porta USB durante conexão VPN Bloqueio de impressão durante
conexão VPN
Proteção contra modificação do registro conexão VPN
Bloqueio de compartilhamento de arquivos durante conexão SSL VPN
Bloqueio da utilização de prompt de comando (DOS)
72. Deve ser possível a criação de políticas de SSL VPN dinâmicas baseadas pelo
menos nos seguintes parâmetros:
Sistema Operacional Utilizado
Anti-vírus
Anti-spyware
Chave de Registro (existência e valor específico a ela atribuído )
Arquivos do sistema
existência de um certificado digital na máquina de onde provém a tentativa de
acesso
Atributos LDAP
Gerenciamento e Conectividade
73. Implementar NTP (Network Time Protocol), conforme RFC 1305, contemplando
autenticação MD5 entre os peers.
74. Deve ser gerenciável via SNMP, SNMPv2c e SNMPv3.
75. Deve ser gerenciável via porta de console, Telnet, SSHv2 e HTTPS.
76. Deve possuir mecanismo interno de captura de pacotes. Deve ser possível
selecionar através de guias de configuração (“wizards”) quais os pacotes (IP de
origem e destino, portas TCP/UDP de origem e destino e interfaces de entrada
devem ser capturados).
77. Deve permitir o armazenamento de pacotes capturados em formato tcpdump.
78. Deve possuir memória flash para armazenamento de imagem do sistema
operacional e arquivos de configuração do equipamento.
79. Implementar completamente a porção cliente do protocolo TACACS+ para
controle de acesso administrativo ao equipamento. Deve ser possível especificar
conjuntos de comandos acessíveis a cada grupo de usuários administrativos e cada
comando deve ser autorizado individualmente no servidor TACACS+. Todos os
comandos executados bem como todas as tentativas não autorizadas de execução
de comandos devem ser enviadas ao servidor TACACS+.
80. Deve vir acompanhado de interface gráfica para gerenciamento das
funcionalidades de
VPN e Firewall.
81. Deve implementar, por interface, as funções de DHCP Server, Client e Relay.
82. Deve suportar a criação de rotas estáticas e pelo menos os seguintes protocolos
de roteamento dinâmicos: RIP, RIPv2 e OSPF. Deve suportar a utilização de pelo
menos dois processos de roteamento simultâneos e independentes.
83. Implementar o protocolo PIM (Protocol Independent Multicast) em Sparse Mode
84. Suporte a operação como IGMP Proxy Agent.
85. Deve suportar inspeção stateful de tráfego IPv6.
86. Deve suportar simultaneamente a criação de regras IPv4 e IPv6.
87. Deve suportar roteamento estático de tráfego IPv6.
88. Deve suportar anti-spoofing (sem uso de ACLs) para endereços IPv6.
89. Deve implementar randomização do número de seqüência TCP para conexões
TCP que trafegam sobre IPv6.
90. Deve suportar pelo gerenciamento sobre IPv6. Devem ser suportados pelo
menos os seguintes protocolos de gerência: Telnet, SSH e HTTPS.
91. Deve suportar stateful failover de conexões IPv6.
92. Deve suportar agrupamento lógico de objetos IPv6 (redes, hosts, serviços) e
criação de regras (ACLs) usando tais objetos.
Resposta 30:
Não existe neste edital um item dedicado a aquisição de IPS.
Pergunta 31:
4.16.5. Acesso e Gerência
Solicitamos um melhor detalhamento das funcionalidades de Gerência, pois o texto
descreve um HW e não uma solução.
Resposta 31:
No item 4.16.5, é solicitado o fornecimento de todos os softwares e licenças
necessárias, caracterizando uma solução de gerência. Este item também trata sobre
o acesso a solução. “A solução ofertada deverá garantir as seguintes
funcionalidades”.
Pergunta 32:
QUESTIONAMENTOS PARA VBLOCK (VCE)
O proponente ou o(s) fabricante(s) deverá(ão) dispor de um centro de manutenção
autorizado no Brasil, devidamente equipado e com pessoal tecnicamente qualificado
para prestar assistência técnica nos equipamentos do sistema, nos períodos de
garantia e pósgarantia
Obs: A VCE não possui suporte dedicado local, somente pelas empresas
fundadoras ( EMC, Cisco ou VMWare ). Desta forma, ou o texto é aberto para
empresas representantes, ou retira-se este item.
Resposta 32:
O texto é claro quando solicita que o Proponente ou o Fabricante deverá dispor de
um centro de manutenção autorizado no Brasil.
Pergunta 33:
Fornecer recursos de escalonamento de chamadas e tempo máximo para solução
por
nível de criticidade, segundo a tabela a seguir:
Criticidade Tempo de Solução Tempo de Resposta
1 - Crítica 30 minutos Imediata
2 - Secundária 8 horas 2 horas
3 - Normal 12 horas 2 horas
Obs: Este ponto também se refere à questão anterior. Em termos de contrato, visto
que os elementos de suporte são remotes, a capacidade da VCE em atender
tempos de resposta em 30 minutos é impactada
Resposta 33:
O texto é claro quando solicita que o Proponente ou o Fabricante deverá dispor de
um centro de manutenção autorizado no Brasil.
Pergunta 34:
Fornecer em cada site chassis com no mínimo 1536 GB de memória RAM DDR3
ECC em pentes de no mínimo 16 GB.
Obs: para 32 servidores (quantidade necessária para atinger os 380 cores), 1536
equivalem à 48 GB por servidor. Em servidores B200 isso equivale à 12 x 4 GB.
Recomendo alterar o texto para no mínimo 4 GB
Resposta 34:
A solicitação não pode ser aceita. O proponente deverá atender os requisitos já
solicitados no edital.
Resposta 35:
Fornecer infra-estrutura de processamento com capacidade de expansão por site de
memória para 3072 GB sem a necessidade de aquisição de nenhum chassis ou
blade adicional de processamento. ( 96 GB por servidor = 12 x 8 GB)
Obs: os servidores B200 para Vblock não trabalham em upgrades. Se possível, já
solicitar os servidores em capacidade maxima ( 96 GB por servidor = 12 x 8 GB)
Resposta 35:
A solicitação não pode ser aceita. O proponente deverá atender os requisitos já
solicitados no edital.
Pergunta 36:
Garantir capacidade de ampliação por site para no mínimo 6TB de memória RAM na
infra-estrutura de processamento da solução de contingência sem aquisição de um
novo bloco de contingência.
Obs: os servidores B200 para Vblock não trabalham em upgrades. Se possível, já
solicitar os servidores em capacidade maxima ( 192 GB por servidor )
Resposta 36:
A solicitação não pode ser aceita. O proponente deverá atender os requisitos já
solicitados no edital.
Pergunta 37:
Fornecer uplinks entre chassis e equipamentos de rede não inferior a seguinte
relação:
Uplink(s) = número de lâminas x 20 GBbps Full Duplex non-blocking.
Obs: As enclosures UCS não seguem este racional. Cada enclosure possui 8
uplinks, e um total de 80 GB/s de tráfego
Resposta 37:
A solicitação não pode ser aceita. O proponente deverá atender os requisitos já
solicitados no edital.
Pergunta 38:
As fontes e ventiladores deverão ser entregues de acordo com a capacidade
máxima do gabinete, ou seja, devem ser provisionadas para a instalação e
configuração de 16 (dezesseis) lâminas de processamento, independente do
número total servidores ou gabinetes solicitados neste edital. As fontes devem ser
do tipo alta eficiência ou possuir eficiência de no mínimo 92%.
Obs:As enclosures UCS não escalam até tal capacidade. As únicas enclosures com
tal capacidade são HP e Dell
Resposta 38:
Entendemos que a questão da capacidade não está limitada conforme mencionado,
dado que a COPEL, para as questões relacionadas a fontes e ventiladores, está
flexibilizando o valor de referência para 16 lâminas que podem ser distribuídas em
chassis distintos.
Pergunta 39:
Possuir no painel do módulo display de operações indicando prioritariamente os
componentes defeituosos.
Resposta 39:
O proponente deverá atender o edital conforme especificado e verificar a resposta
anterior.
Pergunta 40:
Fornecer chassis com no mínimo 14 slots observando o fator de forma exigido,
sendo que estes serão orientados verticalmente, comportando as lâminas de
processamento.
Obs: Estas especificações se referem à laminas HP e Dell, favor retirar para que os
demais concorrentes sejam aptos a participar.
Resposta 40:
O edital exige para o bloco de infra-estrutura de contingência do tipo 1 e para o
fornecimento de chassis com orientação vertical no mínimo 14 slots e 8 blades de no
mínimo de meia altura, já para o fornecimento do item exclusivo de chassis, também
estaremos exigindo no mínimo 14 slots com o fornecimento inicial de 2 blades,
sendo todas no mínimo de meia altura.
A Copel poderá aceitar o fornecimento de blades com orientação horizontal desde
que cada chassis não ocupe mais do que 6 URs excluindo as infra-estuturas de
apoio (conexão) e deve ser tão ou mais eficiente (energia e refrigeração) quanto os
chassis de orientação vertical, neste caso a COPEL aceitará o fornecimento de
blades menores do que meia-altura, dado que a orientação de altura passa a ser
horizontal.
Para o caso do fornecimento horizontal, a Copel aceitará agrupamento de chassis
(item 4.1 e item 4.3. do edital) respeitando os números mínimos de 14 slots, sendo
permitindo neste caso o fornecimento de até 8 chassis por site (requisito do item
4.1.).
Devemos ressaltar que toda Blade deve respeitar os requisitos de performance e
banda, no caso de banda, o edital exige 20 Gbps por lâmina (blade com 2
processadores). Caso sejam fornecidas lâminas de altura inteira com 4
processadores, o troughput deverá ser de no mínimo 40Gbps por lâmina.
Pergunta 41:
A conectividade das lâminas de processamento na largura de banda exigida (20
Gbps por lâmina), deverá ser garantida pelos elementos de conexão ou de extensão
de interfaces.
Obs: Não existem conexões físicas 1:1 no UCS, com oversubscription nos FE das
enclosures UCS
Resposta 41:
A solicitação não pode ser aceita. O proponente deverá atender os requisitos já
solicitados no edital.
Pergunta 42:
Suportar por site no bloco no mínimo 114TB líquidos (sem considerar paridade,
sistema, spare) em base 2, com adição apenas de gavetas, sem inclusão de
controladoras, expansão em discos SAS ou FC, com 15k rpm, utilizando RAID 5,
RAID 6 ou similar com no máximo 6 discos no conjunto, respeitando tamanho
Maximo de disco 600GB com 6Gbps SAS ou 4Gbps FC. A implementação do RAID
deve ser capaz de reconstituir dados provenientes de discos defeituosos, de forma
automática.
A implementação dos níveis de RAID deverá ser feita pelo própriodispositivo de
armazenamento.
Garantir expansibilidade por site no bloco para no mínimo 228TB líquidos e 380
discos com possibilidade de inclusão de controladoras.

Obs: o único Block que atende tal capacidade é o Vblock 300 HX
Resposta 42:
O proponente deverá atender os requisitos já solicitados no edital.
Pergunta 43:
Fornecer todos os softwares e hardwares necessários para execução das aplicações
de virtualização para inicialmente 1.000 UPVs com expansão para 3.000 UPVs.
Obs: Recomendo questionamento neste item, pois, de acordo com os calculos
Copel, isso equivaleira à 96 servidores, sendo um volume maior do que o suportado
em VBlocks da série 300
Resposta 43:
O proponente deverá atender os requisitos já solicitados no edital.
Pergunta 44:
Possuir no mínimo 48 portas 10GBase-X. A Copel poderá utilizar cada porta como
acesso ou uplink.
Obs: Os Vblock possuem 16 uplinks, em maximo, com definições exatas do que é
acesso e uplink
Resposta 44:
O proponente deverá atender os requisitos já solicitados no edital.
Pergunta 45:
Possuir módulos e interfaces Fibre Channel (FC) e Ethernet,realizando todas as
funções de uma SAN.
Possuir interfaces FC (Fibre Channel) com recursos de conexão para Front-End da
infra-estrutura de armazenamento que compõe o “Bloco de infra-estrutura de
contingência do Tipo 1” (item 4.1.3).
Suportar até 8 portas Fibre Channel de 8 Gbps com recursos de redução de
velocidade para adequação a conexões de Front-End de infra-estruturas de
armazenamento de 4Gbps.
Obs: apesar dos switches, servidores e storage do Vblock suportarem FCoE, no
mesmo existe um switch SAN MDS 9148 paras tal tráfego. Assim sendo, a
comunicação FCoE somente ocorre à nível de Enclosure UCS – Fabric Extender. Ou
seja, mesmo que o switch Nexus suporte tal funcionalidade, não sera ofertada com
tais interfaces
Resposta 45:
O proponente deverá atender os requisitos já solicitados no edital.
Pergunta 46:
QUESTIONAMENTOS SERVIÇOS
3.3.8. Serviços de Apoio
Os serviços de instalação, customização, integração e de operação assistida, fazem
parte deste edital. Sendo que a operação assistida deverá ser de 1 (um) ano 9x5
nas dependências da Copel e 24x7 remota.
Entendemos que para atender o item acima, precisamos alocar um recurso
residente no horário comercial pelo período de 1 ano.
A estrutura necessária, como mesa, telefone, notebook, ferramentas de trabalho,
estacionamento, segurança e acesso serão providos pela Copel ou será de
responsabilidade do proponente?
Resposta 46:
O profissional é de inteira responsabilidade da proponente que deverá arcar com
todos encargos e recursos necessários para a execução do trabalho.
Pergunta 47:
3.3.10. Treinamentos
Todos os treinamentos serão certificados pelo fornecedor da solução e compatíveis
tanto em conteúdo como carga horária, com os treinamento oficiais do fabricante.
Entendemos que os treinamentos prestados pelo fornecedor deverão ser oficiais
com certificações do fabricante. Os profissionais da Copel que receberão o
treinamento deverão ser certificados? Os custos dos certificados serão de
responsabilidade da Copel ou da proponente?
Resposta 47:
Os treinamentos deverão ser fornecidos e certificados pelo fornecedor e compatíveis
com os treinamentos oficiais do fabricante. Os profissionais da COPEL serão
preparados para certificação, mas os custos da certificação não estão inclusos no
edital.
Pergunta 48:
3.8. Manutenção e Suporte
A garantia abrange serviços técnicos de manutenção e suporte, contemplando
adequação a infra-estrutura da Copel, suporte, configuração e otimização.
Solicitamos esclarecimento sobre a otimização do ambiente, pois ela acarreta em
um processo de mudança, onde não se aplica o processo de manutenção e
conforme as boas praticas do ITIL, o processo de otimização está inserida na
operação do ambiente que será de responsabilidade da Copel. Está correto o nosso
entendimento?
Atualizar, sem ônus, as novas versões de software, sistemas operacionais, licenças,
incluindo correções e inclusões de novos recursos. As licenças para qualquer
componente poderão sofrer migração de hardware de acordo com as necessidades
da Copel.
Resposta 48:
Entende-se por otimização, melhorias e ajustes que sejam identificados em tempo
de manutenção e suporte.
Pergunta 49:
Para equipamentos desta natureza, a garantia dos equipamentos cobrem os
releases dos softwares (Ex: IOS 1.0 para 1.1 ) e não ou um upgrade de uma versão
de software ( Ex. IOS 1.0 para 2.0 ). Está correto o nosso entendimento?
Resposta 49:
Não. O entendimento não está correto. O upgrade deverá estar incluso.
Pergunta 50:
Fornecimento de chave de acesso (login - via Internet) ao centro de suporte do(s)
fabricante(s) para auxílio a defeitos, correções, atualizações, informações técnicas,
fórums de discussão e tudo o que for necessário aos profissionais da Copel para
suporte e configuração dos recursos que compõem esta facilidade.
Podemos considerar que abertura de chamado ao TAC do fabricante seja de
responsabilidade do gestor do contrato de manutenção, dando visibilidade aos
chamados através de login e senha do fabricante?
Resposta 50:
O proponente deverá fornecer a chave de acesso e senha para acesso direto ao site
do fabricante.
Pergunta 51:
Fornecer recursos de escalonamento de chamadas e tempo máximo para solução
por nível de criticidade, segundo a tabela a seguir: Favor descrever, quais são os
requisitos de criticidade?
Para tempo de resposta imediata, entendemos que será necessária atuação on-site
de uma equipe 24x7, ou podemos considerar um tempo de resposta de 15 minutos?
Resposta 51:
Crítica: Indisponibilidade total do sistema ou serviços. Secundária: Perda de
performance ou indisponibilidade acima de 50% do sistema ou serviços. Normal:
Indisponibilidade parcial do sistema ou serviços abaixo de 50% e/ou Suporte técnico,
incluindo também esclarecimento de dúvidas e pesquisas sobre falhas intermitentes.
Pergunta 52:
No item 3.2, descrição geral, página 2, o edital menciona que deve-se garantir a
compatibilidade da infraestrutura de storage com os padrões iSCSI, FC e FCoE,e
depois no item 4.1.3, pede para fornecer 38Tb líquidos por site utilizando tecnologia
iSCSI, FC ou FCoE. Na seqüência pede para que replicações sejam feitas de forma
assíncrona em links IP para iSCSI 10G ou FcoE, depois que os equipamentos
devem possuir 6 portas 10G suportando protocolo iSCSI nativo, possibilitando a
mesma quantidade para portas FC para fechar pede recursos fibre channel para 4
canais para conexão direta a servidores ou switches. Entendemos que há uma
incoerência na solução, levando-se em consideração que a forma de conectividade
interferirá diretamente no tipo de storage a ser fornecido, bem como o tipo de switch
a ser utilizado para acesso dos servidores aos dados, devendo a Copel definir
exatamente qual tipo de conectividade deverá ser entregue para que as soluções
apresentadas pelos fornecedores sejam equivalentes para que possa existir uma
competitividade de forma saudável como prevêem as leis que regem nosso país.
Resposta 52:
A COPEL pretende com este projeto implantar um ambiente de armazenamento
híbrido: FC e Ethernet, sendo que a conectividade entre sites é provida por infraestruturas Metro Ethernet. Caso a proponente possua uma solução de replicação
distinta a solicitada com performance equivalente ou superior, este deverá
apresentar em sua proposta técnica considerando todos os custos de transporte e
conexões necessárias para atendimento do edital.
Conforme a concepção do edital, existe um item dedicado ao fornecimento de um
Switch Híbrido que reforça a flexibilidade relacionada a conectividade da infraestrutura de storage.
O equipamento Storage deve ser fornecido com interfaces FC ou Ethernet (6x
10Gbps – iSCSI ou FCoE) . A flexibilidade tem por objetivo ampliar a
competitividade, e está explicita no requisito :
“ Fornecer uma quantidade mínima de módulos que garantam o bom desempenho
da solução, utilizando como referência o acesso para escrita e leitura das UPVs para
até 114TB. Como referência, no caso do iSCSI ou FCoE, no mínimo fornecer 6
portas 10Gbps. Sendo que para o FC o número deverá ser equivalente.”
Pergunta 53:
No item 3.2, descrição geral, página 3, o edital diz que deverão ser fornecidas
lâminas de processamento com no mínimo 2 processadores 2,8GHz Hexacore ou
2,2GHz dodecacore, e depois no item 4.1.1 pede processador hexacore de no
mínimo 2,7GHz ou dodecacore de 2,2GHz. Aqui há uma inconsistência na
especificação, o qual compromete o processo licitatório, devendo a Copel corrigir a
especificação e republicar o referido edital.
Resposta 53:
Esclarecendo a sua dúvida, a velocidade solicitada é de 2,7Ghz para o Hexacore e
2,2Ghz para o Dodecacore.
Pergunta 54:
Como a Intel não possui processadores com clock de 2,7GHz, mas sim de 2,66GHz,
entendemos que se optarmos por este processador, nossa proposta técnica será
aceita.
Resposta 54:
A COPEL aceitará desde que comprovadamente equivalente ou superior ao
solicitado no edital.
Pergunta 55:
O índice criado pela Copel para dimensionar a quantidade de lâminas a serem
ofertadas poderá beneficiar um fabricante de processadores, por este possuir
processadores com dodecacore (12 cores). Este fato, aliado a quantidade de
memória a ser endereçado de 6TB sem expansão do que irá ser ofertado, prejudica
outro fabricante, empresa com quem iremos trabalhar neste processo, fazendo com
que a mesma tenha que fornecer o dobro de hardware se utilizar processadores Intel
e servidores de meia altura, inviabilizando a participação neste processo. No caso
de utilizar lâminas de altura inteira, devido a limitação de endereçamento de
memória, haveria necessidade de se incluir 2 chassis na solução, sendo um
incompleto e outro pela metade, o que acarretaria num alto custo o que também
inviabilizaria a participação no processo. Ao analisar os 4 maiores fornecedores de
blades do mercado, três deles estariam em desvantagem neste processo, pois um
único tem condições de atender ao especificado com um único chassis. Desta
forma, entendemos que este índice deve ser reconsiderado, até porque, não tem
como ser auditado, pois no documento ofertado não é explicado quais as métricas
utilizadas para se chegar aos números demonstrados, em tempo, se analisarmos um
índice de mercado como o utilizado pela Vmware ( VMARK ), poder-se-á verificar
que servidores utilizando processadores Intel com 6 ou 8 cores, são mais rápidos
que processadores AMD com 12 cores, e este é um índice público e está disponível
para consulta. Sugerimos que a Copel especifique exatamente a quantidade de
servidores com suas respectivas características para que todos os participantes
possam participar em igualdade de condições, como tem sido todos os processos
dentro do Estado do Paraná, como pode ser verificado junto à Celepar e outros
órgãos do Estado. Assim sendo, a não alteração das especificações citadas, fará
com que não exista uma ampla competitividade e legitimidade no processo licitatório
conforme prevêem as leis 8666/93 e 10520/02.
Resposta 55:
A COPEL Telecomunicações não direciona seus investimentos para nenhum
fabricante em específico.
O índice sugerido pela possível proponente (VMARK), apesar de ser um índice
público, refere-se à medição de performance para um fabricante de software
especifico (Vmware), que também fere o principio supracitado.
Portanto, tanto abertura para fabricantes distintos como o uso de critérios de
avaliação de fácil entendimento e comprovação, promovem uma ampla
competitividade e legitimidade ao edital.
Pergunta 56:
Na página 13, item 4.1.1 - INFRA-ESTRUTURA DE PROCESSAMENTO
consta que a lâmina deverá ser capaz de iniciar sistemas operacionais a partir da
infra-estrutura de conectividade e armazenamento. e na página 15, item 4.1.3 INFRA-ESTRUTURA DE ARMAZENAMENTO o edital pede fornecer sem nenhum
custo adicional a funcionalidade de boot remoto para as UPVs fornecidas na infraestrutura de processamento, no máximo até dezembro de 2011.. A funcionalidade
descrita na página 13 está diretamente ligada com o a disponibilidade da infraestrutura de storage.
Os fabricantes de storage estão constantemente reposicionando seus
equipamentos e inovações recentes como a inclusão de interfaces 10GbE e adesão
massiva da tecnologia FCoE trouxeram inúmeros equipamentos novos, e desta
forma durante os últimos 12 meses muitas funcionalidades foram adaptadas, entre
elas o boot pela rede FCoE e iSCSI. Entendemos que como a data limite para a
homologação dos equipamentos é 09/01/2012, o prazo para provimento de boot
remoto pela infra estrutura de conectividade e de armazenamento poderá ser
apresentada, sem custo, até dezembro de 2012?
Resposta 56:
O entendimento está incorreto. A funcionalidade deverá estar disponível até
dezembro de 2011.
Pergunta 57:
Na página 02, item 3.2 - Descrição Geral, o edital solicita que deve ser
fornecido por site 38TB líquidos de disco SAS ou Fibre Channel (FC), utilizando
como Front-End as tecnologias iSCSI 10Gbps, FC ou FCOE e na página 03 que
deve ser fornecida infra-estrutura de cabeamento enxuta baseada em conectividade
FCoE. Nosso entendimento é que a infraestrutura do ambiente dos servidores deve
possuir conectividade do tipo FCoE para economia de cabeamento e dispositivos,
mas que a opção do front end. da infra estrutura de armazenamento poderá ser
iSCSI ou FC ou FCoE de acordo com o suporte oferecido pela solução e que
soluções FCoE fim a fim (do servidor passando pelos switchs até o storage) são
desejáveis, mas não obrigatórias, podendo em determinado momento serem
convertidas em FC ou iSCSI para interconexão ao storage. Está correto nosso
entendimento?
Resposta 57:
Sim. O entendimento está correto.
Pergunta 58:
Nossa solução suporta o Gzip como ferramenta de compressão de tráfego em
direção aos usuários. A utilização de GZIP permite que o mesmo realize a
compressão de dados com maior confiabilidade que o Deflate (uma vez que o Gzip
adiciona algumas verificações adicionais de CRC quando do ato da compressão)
além de oferecer aos usuários/ desenvolvedores Web maior transparência na
codificação (uma vez que há na indústria uma certa confusão no que diz respeito ao
deflate). Para os usuários que estão acessando o conteúdo o fato da solução
oferecer somente Gzip não traria problemas (uma vez que a maioria esmagadora de
browsers suporta Gzip ou Deflate para a compressão). Logo entendemos que
implementando o Gzip atendemos a necessidade da Copel. Está correto nosso
entendimento?
Resposta 58:
Sim. O entendimento está correto.
Pergunta 59:
Na especificação técnica é solicitada a capacidade para gerenciar os recursos
disponíveis de acordo com as funções habilitadas nos equipamentos SLB, GSLB,
Aceleração Web, etc. Entendemos que, conforme citado no edital, caso haja
impossibilidade no fornecimento parcial ou total dos recursos solicitados a Copel
poderá aceitar a geração de informações de consumo e memória através da
gerência. Está correto nosso entendimento?
Resposta 59:
Sim. O entendimento está correto. “Caso haja impossibilidade no fornecimento
parcial ou total dos recursos solicitados a Copel poderá aceitar a geração de
informações de consumo e memória através da gerência”.
Pergunta 60:
No item 3.2, 4.1.1, 4.5.1 do edital há a seguinte requisição:
Fornecer lâminas de processamento com no mínimo 2 processadores 2,8 GHz
hexacore ou 2,2 GHz dodecacore.
Questão: A COPEL entende como válida a opção de oferecermos lâminas com no
mínimo 2 processadores 2.4GHz decacore (10 cores), respeitando sempre o cálculo
de a cada 1000UPVs=380 cores?
Resposta 60:
Variações dos requisitos exigidos no edital
comprovadamente equivalentes ou superiores.
serão
aceitas
desde
que
Pergunta 61:
Nos itens 3.2, 4.1.1, 4.3.1 do edital há a seguinte requisição:
Fornecer lâminas de processamento com no mínimo 2 (dois) discos internos de 140
GB. Questão: A COPEL entende como válida a opção de oferecermos 2 discos
internos de 100GB SSD (melhor tecnologia do que discos SAS ou SATA)? Levando
em consideração que o boot via SAN torna a solução mais flexível, do que boot via
disco local (tecnologia diskless)!
Resposta 61:
Variações dos requisitos exigidos no edital
comprovadamente equivalentes ou superiores.
serão
aceitas
desde
que
Pergunta 62:
Nos itens 4.1.1, 4.3.1 do edital há a seguinte requisição:
Possuir no painel do módulo display de operações indicando prioritariamente os
componentes defeituosos.
Questão: A COPEL entende como válida a opção do chassi possuir leds indicadores
de eventos juntamente ao software (interface GUI) que identifica minuciosamente
todos os detalhes de um hipotético defeito ou evento no chassi, blades e seus
componentes?
Resposta 62:
O entendimento está correto desde que o proponente forneça todos os softwares,
licenças e quaisquer componentes auxiliares necessários para o atendimento deste
requisito sem nenhum ônus para a COPEL.
Pergunta 63:
Nos itens 4.1.1, 4.3.1 do edital há a seguinte requisição:
Fornecer chassi com no mínimo 14 slots observando o fator de forma exigido, sendo
que estes serão orientados verticalmente, comportando as lâminas de
processamento.
Questão: A COPEL entende como válida a opção do chassi ter no mínimo 8 slots,
em orientação horizontal, comportando as lâminas de processamento? Isso
influencia o bloco de infra-estrutura de contingência do Tipo 1, chassis e orientação!
Resposta 63:
O edital exige para o bloco de infra-estrutura de contingência do tipo 1 e para o
fornecimento de chassis com orientação vertical no mínimo 14 slots e 8 blades de no
mínimo de meia altura, já para o fornecimento do item exclusivo de chassis, também
estaremos exigindo no mínimo 14 slots com o fornecimento inicial de 2 blades,
sendo todas no mínimo de meia altura.
A Copel poderá aceitar o fornecimento de blades com orientação horizontal desde
que cada chassis não ocupe mais do que 6 URs excluindo as infra-estuturas de
apoio (conexão) e deve ser tão ou mais eficiente (energia e refrigeração) quanto os
chassis de orientação vertical, neste caso a COPEL aceitará o fornecimento de
blades menores do que meia-altura, dado que a orientação de altura passa a ser
horizontal.
Para o caso do fornecimento horizontal, a Copel aceitará agrupamento de chassis
(item 4.1 e item 4.3. do edital) respeitando os números mínimos de 14 slots, sendo
permitindo neste caso o fornecimento de até 8 chassis por site (requisito do item
4.1.).
Devemos ressaltar que toda Blade deve respeitar os requisitos de performance e
banda, no caso de banda, o edital exige 20 Gbps por lâmina (blade com 2
processadores). Caso sejam fornecidas lâminas de altura inteira com 4
processadores, o troughput deverá ser de no mínimo 40Gbps por lâmina.
Pergunta 64:
Nos itens 3.2, 4.3.1, 4.5.1 do edital há a seguinte requisição:
Fornecer lâminas de processamento que ocupem no mínimo meia altura de um
chassi.
Fornecer lâminas de processamento que ocupem no máximo meia altura de um
chassi.
Questão: A COPEL entende como válido a opção da lâmina ocupar no mínimo 1/4
da altura de um chassis? Levando em consideração que as lâminas serão dispostas
horizontalmente, em 2 colunas de lâminas!
Resposta 64:
Conforme definido acima (ver Resposta 63), a Copel aceitará a disposição horizontal
desde que os requisitos de throughput (20 Gbps para 2 processadores),
performance e eficiência (refrigerarão e alimentação) sejam iguais ou superiores e
os limites de ocupação sejam respeitados.
Pergunta 65:
Nos itens 3,2 4.1.1 do edital há a seguinte requisição:
Fornecer no máximo 4 Chassis com no mínimo 8 blades (lâminas) cada por site.
Garantir capacidade de ampliação por site, para o dobro de blades (Lâminas) de
processamento propostas no “Bloco de infra-estrutura de contingência Tipo 1”.
Questão: A COPEL entende como válida a opção de se instalar no máximo 3
chassis 6RU (20 lâminas) para o bloco de contingência 1, sendo assim 2 chassis
com 8 lâminas e 1 chassis com 4 lâminas? Pois a partir do momento em que se
duplicar esses valores por site (expansão), o número máximo agrupado de chassis
por site será superior a 4.
Resposta 65:
Sendo respeitado o valor de no mínimo 8 Blades por chassis com 14 slots e
respeitando o número de UPVs com as características mínimas exigidas, a Copel
aceitará na disposição horizontal até 8 chassis por site. Ver complementação de
requisitos conforme respostas 63 e 64.
Pergunta 66:
Nos itens 4.1.1, 4.3.1 do edital há a seguinte requisição:
Capacidade de expansão para até 16 (dezesseis) lâminas de meia altura.
As fontes e ventiladores deverão ser entregues de acordo com a capacidade
máxima do gabinete, ou seja, devem ser provisionadas para a instalação e
configuração de 16 (dezesseis) lâminas de processamento, independente do
número total servidores ou gabinetes solicitados neste edital. As fontes devem ser
do tipo alta eficiência ou possuir eficiência de no mínimo 92%.
Questão: A COPEL entende como válida a opção de oferecer chassis com expansão
de no máximo 8 lâminas de 1/4 de altura?
Resposta 66:
Conforme definido anteriormente (ver resposta 63), a Copel aceitará chassis com 8
lâminas desde que respeitado o número de 14 slots por agrupamento. Ver respostas
63, 64 e 65.
Pergunta 67:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Fornecer todos os softwares e hardwares necessários para execução das atividades
de gerência.
Questão: Esta especificação limita-se ao escopo do edital ou devemos prever o
gerenciamento de outros recursos da Copel?
Resposta 67:
O fornecimento limita-se apenas e exclusivamente ao escopo requisitado pelo Edital.
Pergunta 68:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Fornecer recursos de redundância.
Questão: Qual o tipo de redundância esperado?
Resposta 68:
Conforme solicitado no edital, a gerência deverá ser uma solução de alta
disponibilidade que garanta que a perda de elementos da infra-estrutura de
conectividade ou elementos de rede não afete o acesso e o uso da infra-estrutura de
gerência.
Pergunta 69:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Garantir recursos para integração com os sistemas de gerência da Copel.
Questão: Quais são os sistemas com os quais a solução deve se integrar?
Resposta 69:
A solução de gerência deverá se integrar com o sistema HPOpenView, CA Ehealth e
plataformas abertas como Cacti, MRTG, Sistema comercial da Telecom e scripts da
COPEL.
Pergunta 70:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Fornecer recursos para gerenciar cada componente da infraestrutura de
contingência pertencentes à solução.
Questão: Quais modalidades de gerenciamento? Disponibilidade, Performance,
Configuração?
Resposta 70:
A solução ofertada deverá ser fornecida com as disciplinas de Configuração,
Disponibilidade e Performance. Desejável SLA.
Pergunta 71:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Possuir recursos para gerenciar toda infra-estrutura de contingência, uma única
infra-estrutura de gerência redundante, com um ou vários componentes, deverá ser
capaz de gerenciar todos os blocos da solução de contingência.
Questão: Seria possível um maior detalhamento do requerimento?
Resposta 71:
A infra-estrutura de gerência deve ser fornecida com recursos que permitam o
gerenciamento de toda a solução de contingência. Esta infra-estrutura poderá ser
composta por vários componentes, sempre respeitando a característica de alta
disponibilidade.
Pergunta 72:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Possuir recursos que permitam que os servidores e suas propriedades de I/O sejam
monitorados e provisionados através de perfis de serviços, gerando alertas de falhas
ou de carga.
Questão: Seria possível um maior detalhamento do requerimento?
Resposta 72:
É de fundamental importância que a infra-estrutura de gerência possa monitorar os
eventos relacionados às lâminas/blades fornecidas na solução. Sendo I/O um dos
atributos de extrema importância para a solução de contingência, portanto este
parâmetro deve ser monitorado pela plataforma. Perfis de serviços, neste caso, são
úteis para otimização operacional.
Pergunta 73:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Gerenciar infra-estrutura ativada e desativada de forma automática, devendo este
processo ser integrado com a infraestrutura de comercialização da Copel,
gerenciando também esta comunicação.
Questão: O objetivo deste item é saber se a capacidade de recursos de TI
disponíveis atende a demanda de negócios?
Se a resposta for afirmativa, esta funcionalidade constará do processo de
homologação? Favor descrever o processo de homologação para a mesma.
Resposta 73:
O objetivo deste requisito é garantir a mediação para as atividades de ativação e
desativação dos elementos da infra-estrutura com o sistema comercial da
telecomunicações garantindo assim, a automatização do processo de fornecimento
de serviços provisionados pela COPEL ou diretamente pelo cliente. Durante a
homologação deverá ser demonstrado que a solução proposta possui recursos para
atendimento deste requisito.
Pergunta 74:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Garantir que os servidores sejam alocados e realocados de acordo com as cargas
de trabalho da aplicação num mesmo site ou em sites distintos.
Questão: É necessário indicar com qual serviço (pacote que foi comercializado) este
servidor está relacionado?
Se a resposta for afirmativa, esta funcionalidade constará do processo de
homologação? Favor descrever o processo de homologação para a mesma.
Resposta 74:
Os serviços podem ser alocados em um mesmo site ou em sites distintos
dependendo da carga demandada pela aplicação ou por motivação operacional.
Pergunta 75:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Possuir recursos para carregar um perfil de serviço em um servidor, sendo que a
configuração dos dispositivos e elementos envolvidos no processo seja realizada de
maneira automática, eliminando etapas manuais para realizar tal configuração.
Questão: Em nosso entendimento Perfil de Serviço significa um conjunto de software
(SO, Application Server, Application, Database, IOS) e configurações de recursos a
serem carregados.
É necessário ter uma base de software que permita criar os pacotes que serão
carregados, independente do conteúdo de imagens pré-definidas?
Se a resposta for afirmativa, esta funcionalidade constará do processo de
homologação? Favor descrever o processo de homologação para a mesma.
Resposta 75:
Sim. Está correto o entendimento. Para o caso da homologação esta funcionalidade
deverá ser demonstrada para alguns perfis.
Pergunta 76:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Assegurar o cumprimento de configuração através de seus ambientes físicos e
virtuais para automatizar e controlar as alterações de configuração em um servidor.
Questão: É necessário que qualquer alteração de configuração nesses ambientes
seja identificada automaticamente pela solução de gerenciamento, permitindo a
tomada de ações baseadas em políticas?
Resposta 76:
As alterações de configurações que devem ser identificadas estão relacionadas
apenas à ativação e desativação dos serviços.
Pergunta 77:
É necessário gerenciar a conformidade dos ambientes de acordo com as
regulamentações do mercado (SOX, PCI, etc.), ou normas da empresa e criar
pacotes de correções para serem distribuídos?
Se a resposta for afirmativa, esta funcionalidade constará do processo de
homologação? Favor descrever o processo de homologação para a mesma.
Resposta 77:
O foco da solução é o fornecimento do serviço de infra-estrutura e não o
atendimento de requisitos corporativos de cada cliente.
Pergunta 78:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Possuir recursos para controlar as alterações realizadas no ambiente, gerando logs
de acesso e relatórios de uso para auditoria.
Questão: É necessário que essas alterações possam ser desfeitas
automaticamente, baseadas em políticas?
Se a resposta for afirmativa, esta funcionalidade constará do processo de
homologação? Favor descrever o processo de homologação para a mesma.
Resposta 78:
As alterações de configurações devem ser identificadas. Seria desejável a
funcionalidade citada, porém este não é um requisito do edital.
Pergunta 79:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Fornecer gestão completa do inventário dos recursos disponíveis na infra-estrutura
de contingência.
Questão: Podemos considerar que gestão completa do inventário de recursos inclui
apresentar o relacionamento entre os recursos e os serviços suportados por eles,
sendo possível, assim, que num planejamento de mudanças ou no recebimento de
um evento de infra-estrutura, seja possível identificar quais serviços seriam
impactados?
Se a resposta for afirmativa, esta funcionalidade constará do processo de
homologação? Favor descrever o processo de homologação para a mesma.
Resposta 79:
Sim. Será considerada está alternativa. No caso de implementação, deverá ser
demonstrada no processo de homologação.
Pergunta 80:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Possuir recursos de descoberta automática de dispositivos que são adicionados,
movidos ou removidos do sistema, adicioná-los ao seu inventário e aplicar as
configurações de maneira apropriada.
Questão: É necessário que o inventário apresente o relacionamento entre os
recursos e os serviços que eles suportam sendo possível, assim, que num
planejamento de mudanças ou no recebimento de um evento de infra-estrutura, seja
possível identificar quais serviços seriam impactados?
Se a resposta for afirmativa, esta funcionalidade constará do processo de
homologação? Favor descrever o processo de homologação para a mesma.
Resposta 80:
Sim. Será considerada está alternativa. No caso de implementação, deverá ser
demonstrada no processo de homologação.
Pergunta 81:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Possuir integração otimizada com ferramentas de sistemas de nível mais alto
cobrindo todo ciclo de vida operacional, desde a implantação até o monitoramento e
a análise.
Questão: Essas ferramentas já estão implementadas na Copel ou devem ser
oferecidas? Se já estiverem na Copel, especificar quais são e qual o nível/tipo de
integração esperado.
Favor descrever o processo de homologação.
Resposta 81:
A integração será realizada com os sistemas de gerência e comercial da Copel.
Pergunta 82:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Permitir a criação de catálogo de perfis de serviço aplicável a toda infra-estrutura.
Entendemos que Perfis de Serviço sejam as ofertas de serviços que podem ser
requisitadas pelos usuários, está correto?
Questão: Se sim, é necessário que a solução de gerência permita criar diagramas
dos serviços oferecidos que sejam utilizados na criação das ofertas de serviços e
que essas ofertas sejam publicadas no portal de usuários automaticamente?
Se a resposta for afirmativa, esta funcionalidade constará do processo de
homologação? Favor descrever o processo de homologação para a mesma.
Resposta 82:
A solução deve permitir a criação de um catálogo de produtos, mas deverá ser
integrada ao sistema comercial da COPEL. Durante a homologação deverá ser
demonstrado.
Pergunta 83:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Fornecer recursos para o provisionamento automático da recuperação de desastre
da infra-estrutura de um site (site backup ativo-ativo).
Questão: É necessário que este procedimento seja baseado em workflows
automatizados que interajam com os recursos do site de forma agnóstica (que um
único workflow automaticamente identifique e execute o processo mesmo que
existam recursos de fornecedores diferentes na mesma infra-estrutura)?
Se a resposta for afirmativa, esta funcionalidade constará do processo de
homologação? Favor descrever o processo de homologação para a mesma.
Resposta 83:
Sim. Será considerada está alternativa. No caso de implementação, deverá ser
demonstrada no processo de homologação.
Pergunta 84:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Assegurar integração com as soluções de gerência existentes na Copel e com os
outros sistemas de gerência que compõem a própria solução.
Questão: Quais são as soluções da Copel com os quais a solução deve se integrar?
Qual o nível de integração esperado?
Favor descrever o processo de homologação.
Resposta 84:
A solução de gerência deverá se integrar com o sistema HPOpenView, CA Ehealth e
plataformas abertas como Cacti, MRTG. Integração também deverá ocorrer com o
Sistema comercial da Telecom e scripts da COPEL.
Pergunta 85:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Fornecer ferramenta de simulação de dimensionamento para atendimento de
demandas inesperadas.
Questão: Esta ferramenta deverá oferecer simulações individuais para servidores,
rede, storage, hardware, etc., ou é necessária a simulação no nível de serviço
oferecido?
Resposta 85:
Esta funcionalidade têm por objetivo simular demanda por recursos. Esta
funcionalidade deverá ser demonstrada na homologação.
Pergunta 86:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Possuir recursos para guiar o usuário (administrador) pelos passos necessários para
inicializar o sistema de armazenamento e configurar seus parâmetros de rede.
Questão: É necessário que a solução suporte sistemas de armazenamento de
diferentes fornecedores?
Se a resposta for afirmativa, esta funcionalidade constará do processo de
homologação? Favor descrever o processo de homologação para a mesma.
Resposta 86:
Este requisito não é exigido no edital. Porém seria desejável.
Pergunta 87:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Possuir recursos para descobrir os sistemas de storage com recursos para
configurar e alocar storage.
Questão: É necessário que a solução suporte sistemas de armazenamento de
diferentes fornecedores?
Se a resposta for afirmativa, esta funcionalidade constará do processo de
homologação? Favor descrever o processo de homologação para a mesma.
Resposta 87:
Este requisito não é exigido no edital. Porém seria desejável.
Pergunta 88:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Permitir a administração centralizada, por meio de uma console de gerência
acessada via web browser com controle de acesso seguro via HTTPS e/ou SSH,
com alta disponibilidade, permitindo, por exemplo, o gerenciamento dos sistemas de
armazenamento localmente na mesma LAN ou remotamente pela Internet ou rede
MPLS, usando um browser comum.
Questão: É necessário que a solução tenha API para permitir o “transbordo” de
requisições de serviços para outro parceiro, mantendo o gerenciamento dos
recursos que estiverem rodando nesse parceiro?
Se a resposta for afirmativa, esta funcionalidade constará do processo de
homologação? Favor descrever o processo de homologação para a mesma.
Resposta 88:
Este requisito não é exigido no edital. Porém seria desejável.
Pergunta 89:
No item 4.1.4. (Infra-estrutura de gerência) do edital há a seguinte requisição:
Possuir recursos de notificação de eventos críticos e mudanças, possibilitando uma
administração pró-ativa.
Questão: É necessário que as notificações sejam geradas com base em limiares
dinâmico de serviço, automaticamente descobertos pela solução de gerência?
Se a resposta for afirmativa, esta funcionalidade constará do processo de
homologação? Favor descrever o processo de homologação para a mesma.
Resposta 89:
Este requisito não é exigido no edital. Porém seria desejável.
Recomendações COPEL:
1- A versão do edital está disponível no site da COPEL.
2- No próximo dia 17 de outubro, conforme previsto no edital de homologação
pública, reforçamos que cada proponente não deverá esquecer de fornecer os
seguintes itens:
-Arquitetura detalhada da solução (diagramas, textos explicativos e
considerações pertinentes);
-Caderno de testes detalhado. Referenciar os requisitos do edital e
relacionar aos testes que serão realizados. Fornecer referencial técnico
detalhado (URL específica e/ ou manuais com capitulo, página e parágrafo).
-Verificar todos os requisitos a serem fornecidos no documento
denominado de “Proposta Técnica” (Ver edital de homologação no site da
COPEL).
Este esclarecimento passa a integrar o edital de Licitação.
Favor confirmar o recebimento deste.
Atenciosamente,
Mauro Eduardo Clepf
Superintendente de Telecomunicações em exercício