TERMO DE REFERÊNCIA
ESTADO DE GOIÁS SECRETARIA DE ESTADO DA EDUCAÇÃO
SUPERINTENDÊNCIA DE TECNOLOGIA
TERMO DE REFERÊNCIA
1. OBJETO
1.1. Aquisição de solução hiperconvergente com armazenamento para atender a Secretaria de Estado de Educação de Goiás do Governo do Estado de Goiás, conforme especificações e condições constantes deste Termo de Referência.
2. JUSTIFICATIVA
2.1. A aquisição de 09 (nove) nós de servidores hiperconvergentes servirá para substituir, ampliar e consolidar toda a infraestrutura de servidores e
armazenamento atualmente em uso na Secretaria de Estado de Educação de Goiás, que encontra-se obsoleta (08 anos de utilização), sem garantia, e com capacidade de processamento inferior à demanda dos sistemas atuais.
2.2. A solução hiperconvergente adota componentes definidos por software, combinando recursos de computação, armazenamento e rede em uma camada unificada de gestão, oferecendo benefícios de um Data Center virtualizado em um sistema mais econômico, com fácil implantação e gerenciamento.
2.3. A solução é composta por 01 (um) Lote apenas devido a sua interoperabilidade e para evitar que o processo não seja adjudicado e cause
prejuízo do conjunto da solução, tendo em vista que os mesmos são interdependência na composição da integração e compatibilidade, ou seja, a não contratação de um deles pode gerar riscos no fornecimento da solução como um todo e inviabilizar a implantação eficaz do ambiente, deixando de atender o objetivo da aquisição.
2.4. Outro fator importante é evitar que após a solução instalada, e havendo contratações desmembradas, caso ocorra alguma indisponibilidade
ou mau funcionamento de um dos vários elementos do sistema, os diferentes fornecedores passem a debater quanto à responsabilidade pelo restabelecimento do serviço, seja pela falta de diagnóstico preciso em termos de “causa da falha”, seja por alegações quanto à competência contratual em intervenções nos produtos de diferentes fornecedores que integram a solução. Dessa forma, um único ponto de contato na gestão dos contratos irá proporcionar maior agilidade na resolução de problemas - com economicidade - advindos de falhas de equipamentos ou outros eventos relacionados ao contrato de fornecimento.
2.5. Os equipamentos de processamento e armazenamento distribuídos, visam lidar com as atuais dificuldades de manutenção, empregando novas
tecnologias que permitam tanto implementar melhorias no Datacenter quanto endereçar a necessidade de expansão do ambiente tecnológico hoje já saturado, por meio de aquisição de recursos modernos de qualidade, com garantia da continuidade dos serviços críticos de tecnologia da informação que suportam e apoiam a Secretaria de Estado da Educação de Goiás no cumprimento de sua missão institucional.
2.6. A solução representa a combinação de componentes virtuais e físicos de uma infraestrutura, tais como servidores, redes e hardware de
armazenamento, resultando em um único dispositivo controlado por software, dispondo de melhor gerenciamento da infraestrutura do Datacenter, combinando recursos e plataformas que atualmente são diferentes e inserindo uma camada de gerenciamento em todo o sistema resultante, tornando-o mais simples e integrado.
2.7. O armazenamento definido por software ou solução integrada de armazenamento e processamento de dados hiperconvergente proporcionará
a disponibilidade e segurança pois os dados serão replicados em diversos equipamentos, o desempenho e principalmente a escalabilidade horizontal, ou seja, a expansão de armazenamento ou processamento ocorrerá com a inserção de novos nós ao ambiente, sendo que cada equipamento individual de armazenamento e processamento será considerado um nó.
2.8. Com a possibilidade da escalabilidade horizontal, eliminamos a necessidade de substituição do ambiente sempre que extinguir o serviço de
suporte do fabricante, pois, existe a possibilidade de inserção de novos nós que complementarão o ambiente mantendo um ambiente distribuído em diversos equipamentos.
2.9. Com a concretização desta Adesão espera-se os seguintes benefícios e melhorias no cenário atual do ambiente tecnológico da Secretaria de Estado da Educação de Goiás:
CENÁRIO ATUAL | CENÁRIO PRETENDIDO | BENEFÍCIOS |
Serviços hospedados no Datacenter em 20 (vinte) servidores físicos. | Serviços hospedados no Datacenter consolidados em apenas 09 (nove) servidores físicos. | - Redução da complexidade do ambie - Melhoria da Gestão e Administração - Redução nos custos indiretos com en |
Todos os Servidores Físicos do Datacenter sem possibilidade de Renovação de Garantia pelo Fabricante. | Todos os Servidores Físicos do Datacenter com Garantia On-site por 60 meses. | - Aumento da Disponibilidade e da Se tecnológico. |
Servidores do Datacenter com 08 anos de uso, fora da linha de produção do fabricante e com baixo poder de processamento (Processadores Intel® Xeon® E5-2620 v0). | Servidores do Datacenter novos, com componentes de última geração e com alto poder de processamento e desempenho. | Melhoria na performance dos serviços hospedadas, principalmente no cálculo no Sistema Administrativo Pedagógic os professores da rede estadual. |
Custo elevado no licenciamento de softwares e aplicações que utilizam como métrica a quantidade de núcleos ou de processadores. | Custo de licenciamento adequado aos benefícios alcançados. | - Otimização na utilização dos recurso - Melhoria no retorno sobre o investim aquisição de licenças. |
3. DAS QUANTIDADES E VALORES
Lote | Item | Descrição | Totais ATA | QTD | Modelo | Valor | Unitário | (R$) | Valor | Total (R$) |
1 | 1 | Servidor 1 | 11 | 5 | Servidor Nutanix NX-8035-G7 | R$ | 444.492,28 | R$ | 2.222.461,40 | |
3 | Servidor 3 | 8 | 4 | Servidor Natanix NX-1065-G7 | R$ | 306.590,15 | R$ | 1.226.360,60 | ||
5 | Switch 2 | 11 | 2 | Arista 7150S | R$ | 94.527,77 | R$ | 189.055,54 | ||
6 | Módulo 1 | 10 | 4 | Gbic Rj-45 1GbE | R$ | 2.190,42 | R$ | 8.761,68 | ||
7 | Módulo 2 | 44 | 4 | Gbic 10GbE SR SFP+ | R$ | 3.942,76 | R$ | 15.771,04 | ||
VALOR TOTAL | R$ | 3.662.410,26 | ||||||||
VALOR TOTAL: R$3.662.410,26 (Três Milhões e Seiscentos e Sessenta e Dois Mil e Quatrocentos e Dez Reais e Vinte e Seis Centavos).
SOLUÇÃO HIPERCONVERGENTE COM ARMAZENAMENTO, PROCESSAMENTO, VIRTUALIZAÇÃO E ORQUESTRAÇÃO COM PROTEÇÃO DE DADOS
4. SOLUÇÃO HIPERCONVERGENTE COM ARMAZENAMENTO, PROCESSAMENTO, VIRTUALIZAÇÃO E ORQUESTRAÇÃO COM PROTEÇÃO DE DADOS
4.1. REQUISITOS GERAIS
4.1.1 Adquirir servidores para expansão de solução hiperconvergente Nutanix com armazenamento, processamento e orquestração com proteção de dados;
4.1.2 Compatibilizar com a atual solução hiperconvergente da Secretaria de Estado da Educação - SEDUC;
4.1.3 Ser composto por todas as partes e soGwares neste termo de referência, incluindo licenciamento do soGware necessário para o completo atendimento da especificação técnica, hipervisor, na modalidade de uso perpétuo, ou seja, os servidores e sistemas devem continuar a operar normalmente mesmo após o período de suporte e direito de atualização ativos e deverão ser fornecidas na capacidade máxima dos equipamentos fornecidos;
4.1.4 Ser projetado, desenvolvido, testado e homologado para o soGware proposto, desde que o suporte e garantia de ambos sejam prestados por um único fornecedor, inclui-se o hardware e soƒware propostos;
4.1.5 Existir como produto único antes da publicação desse documento, caracterizando tecnologia integrada de armazenamento, processamento, orquestração com backup.
4.1.6 Não serão aceitos equipamentos ou componentes que tenham sido descontinuados pelo fabricante ou que estejam listados para descontinuidade futura (deprecated) na data da análise das propostas, ou ainda, equipamentos desenvolvidos única e exclusivamente para o presente certame;
4.1.7 Entender que a denominação, servidor é sinônimo de nó, appliance ou lâmina;
4.1.8 Prover uma infraestrutura integrada de alta disponibilidade em configuração de cluster para ambientes virtualizados. Não serão aceitas soluções ou funcionalidades implementadas via soƒware ainda em fase de desenvolvimento, ou seja, àquelas que ainda não foram homologadas para ambientes de produção;
4.1.9 Ter compatibilidade com o virtualizador Nutanix Acropolis Hipervisor versão mínima 5.5 ou superior;
4.1.10 Possuir garantia e suporte por 3 (três) anos na modalidade 24x7x365, e troca de peças no próximo dia útil. O canal de chamados de suporte deverá ser responsável pelo hardware e soƒware de modo global empregados nesta solução integrada. O tempo de resposta máximo para um chamado técnico aberto com prioridade máxima deverá ser de 2 (duas) horas. É sem limites de requisições para suporte;
4.1.11 Suportar servidores com diferentes especificações de hardware, no mesmo cluster ou futuros, servidor com configurações distintas de processadores, memória RAM e discos SSD e rígidos, conforme tabela 1 – Modelo.
4.2. CARACTERÍSTICAS DE SOFTWARE HIPERCONVERGENTE
4.2.1. Replicar automaticamente todas as gravações para um ou mais servidores do cluster, utilizando as interfaces de maior velocidade (throughput) presentes em cada um dos servidores, as quais deverão ser de no mínimo de 10Gbps com redundância;
4.2.2. Garantir que os dados estejam sempre gravados em mais de um servidor ao mesmo tempo, se houver mais de um chassi ou servidores os dados deverão ser gravados preferencialmente nos equipamentos adjacentes, permitindo o pleno funcionamento do ambiente mesmo com a total indisponibilidade de um ou dois servidores, dependendo da configuração;
4.2.3. Permitir a escolha de 2 (duas) ou 3 (três) réplicas de dados, dependendo da configuração e da disponibilidade desejada;
4.2.4. Permitir escalabilidade horizontal, isso é, a adição de novos chassis ou novos servidores ao cluster através de uma console gráfica, sem a parada do ambiente de produção, aumentando como um todo a capacidade de armazenamento, processamento e memória disponibilizados ao hipervisor, além de crescer de forma linear o desempenho do cluster;
4.2.5. Todos os discos de estado sólido (SSD - flash) deverão ser do tipo missão crítica (enterprise-class);
4.2.6. As operações de leitura deverão ocorrer a partir de um cache unificado e deduplicado, que compreenda parte da memória RAM da controladora de armazenamento (seja integrada do hipervisor ou virtual) e parte do discos SSD;
4.2.7. Toda operação de gravação de uma determinada máquina virtual deverá acontecer primariamente nos discos SSD daquele servidor que está hospedando a máquina virtual. Caso o disco SSD local esteja com alta taxa de ocupação, a operação de gravação deverá ser redirecionada para um disco SSD pertencente a outro servidor do cluster;
4.2.8. Utilizar mecanismo para mover os dados não acessados para os discos rígidos pertencentes ao cluster, deixando os discos SSD de cache para dados acessados com frequência. Caso o dado volte a ser requisitado, o mesmo deverá ser migrado para o cache unificado, somente para plataformas híbridas;
4.2.9. As controladoras de armazenamento virtual ou integrada ao hipervisor deverão manter os dados distribuídos uniformemente através de todos os discos SSD e rígidos conectados aos servidores pertencentes ao cluster. A distribuição dos dados deverá ser um processo automático agendado pelo soƒware ou disparado assim que uma determinada porcentagem de utilização do discos daquele servidor for atingida;
4.2.10. Durante o processo de gravação de dados no cluster distribuído a solução deverá ser capaz de fazer o cálculo de integridade com degradação mínima de desempenho e armazená-lo. No momento da leitura, deve-se realizar a verificação da consistência dos dados via com o valor de integridade número armazenado. Não sendo possível, desabilitar essa funcionalidade;
4.2.11. Manter os dados das máquinas virtuais no armazenamento local do próprio servidor, e caso essa máquina virtual se movimente de um servidor a outro, os dados devem ser movidos, caso necessário em segundo plano, para esse novo servidor, buscando o melhor desempenho possível;
4.2.12. Trabalhar com o conceito de pool armazenamento, formado pelo conjunto de todos os discos rígidos e discos SSDs presentes no cluster. O pool de armazenamento poderá ser expandido com novos discos à medida que novos servidores são adicionados ao cluster;
4.2.13. Permitir a criação de um subconjunto do espaço disponibilizado pelo cluster lógico integrado denominado volume de dados. O volume de dados é a unidade de armazenamento compartilhada apresentada ao hipervisor, onde serão armazenados os discos virtuais, aos quais poderão possuir o tamanho total do cluster lógico de armazenamento ou reserva de espaço conforme política configurável pela interface gráfica;
4.2.14. Deverá permitir a criação de no mínimo 3 (três) volumes de dados (datastore) com diferentes características e propriedades de otimização de espaço e desempenho habilitados ou desabilitados;
4.2.15. Os volumes de dados presente no cluster integrado, deverá suportar o tamanho máximo de disco virtual suportado por cada hipervisor;
4.2.16. O sistema distribuído de arquivos empregado pela solução deverá prover os seguintes protocolos: NFS (Network Files System), iSCSI (Internet Small Computer System Interface), SMB 3.0 (Server Message Block);
4.2.17. Prover em cada um dos servidores, atualizações do tipo “menor esforço” (um-clique), possibilitando a atualização de todos os servidores do cluster de forma simples e automatizada, eliminando a intervenção manual do administrador e necessidade de parada completa do ambiente. Essa funcionalidade deverá atualizar os seguintes componentes:
4.2.17.1 Sistema operacional do controlador de armazenamento virtual;
4.2.17.2 Hipervisor;
4.2.17.3 Micro-códigos de discos rígidos e flash;
4.2.17.4 BMC/IPMI (ou similar) e BIOS;
4.2.17.5 Ferramenta de monitoramento do cluster
4.2.18. Suportar o inventário e o gerenciamento do ciclo de vida dos principais componentes do Cluster, ou seja, versões das camadas de soGware e micro-códigos do hardware;
4.2.19. Prover, via soƒware, compressão inline (durante o processo de gravação). Essa funcionalidade deverá utilizar bibliotecas, que oferece uma boa taxa de compressão com baixo custo computacional;
4.2.20. Prover, via soƒware, deduplicação de dados inline (durante o processo de leitura), permitindo a granularidade de habilitá-lo por máquina virtual. A funcionalidade deverá atuar na camada de performance presente em cada um dos servidores, composta por memória RAM e discos SSD. Essa técnica deverá se beneficiar da aceleração específica oferecida pelos atuais processadores;
4.2.21. Prover compressão pós-processada, sendo que após uma operação de escrita, exista um atraso em minutos para iniciar o processo de compressão. O atraso deverá ser configurável pelo administrador do sistema. A compressão deverá se utilizar de técnicas de processamento paralelo distribuído, distribuindo o custo computacional da compressão entre diversos servidores pertencentes ao cluster;
4.2.22. Prover deduplicação pós-processado, que diferentemente da inline, deverá atuar nos discos rígidos utilizados na solução. A deduplicação deverá ocorrer em um processo posterior a gravação e utilizar de técnicas de processamento paralelo distribuído, otimizando a capacidade de armazenamento;
4.2.23. Prover um melhor aproveitamento dos recursos de armazenamento do cluster, implementar método de proteção de dados Erasure Coding, no qual os dados são divididos em fragmentos, estendidos e codificados com pedaços de dados redundantes e armazenados em diferentes servidores. Esse método deverá utilizar técnicas de processamento paralelo distribuído no cluster para calcular a paridade dos blocos;
4.2.24. Prover capacidade de alocar e fixar determinadas máquinas virtuais nos discos SSD, garantindo melhor performance possível, em modelos híbridos;
4.2.25. Suportar integração com os seguintes componentes a fim de aumentar a velocidade das operações de snapshots e clones, diminuindo a penalidade no cluster integrado;
4.2.26. Prover snapshots por máquina virtual nativamente independente do hipervisor, armazenando esses snapshots no
cluster para proteção local. O snapshot criado deve ser do tipo consistência de erros, ou seja, o snapshot poderá ser feito com o ambiente em produção e deverá garantir a proteção dos dados que estão gravados em disco e a integridade do sistema operacional da VM;
4.2.27. Permitir ao usuário de uma determinada máquina virtual, restaurar arquivos armazenados em snapshots a partir da máquina virtual em execução. Essa funcionalidade deve exigir mínima intervenção manual do administrador da solução de armazenamento;
4.2.28. Prover acesso a armazenamento via protocolo iSCSI, em nível de blocos a uma ou mais máquinas virtuais ou fisicas externa ao ambiente integrado, visando atender aplicações em alta disponibilidade;
4.2.29. O recurso de snapshots das máquinas virtuais em nível de storage, deve suportar um número ilimitado de snapshots, beneficiando-se de algoritmo que redireciona a escrita para o snapshot, oferecendo mais velocidade e eficiência, sem sacrificar a performance do cluster;
4.2.30. Prover também cópias do tipo consistência de aplicação, onde no momento da execução a camada de soGware é avisada sobre a operação e entrada em estado de integridade;
4.2.31. Permitir a criação de grupos de consistência para a replicação, permitindo que, no momento da restauração ou do desastre, todas as máquinas virtuais contidas nesse grupo voltem ao mesmo ponto no tempo;
4.2.32. Não deve apresentar limites de pontos de consistência (snapshots) por máquina virtual no que tange cópias locais e replicação entre sites, o único fator tolerado será a quantidade de objetos gerenciados pelo cluster integrado;
4.2.33. A funcionalidade de replicação nativa da solução deverá trabalhar com snapshots das máquinas virtuais e suportar as seguintes topologias de interconexão entre clusters localizados em diferentes locais: um para um, um para vários, vários para um e vários para vários;
4.2.34. A replicação assíncrona deverá prover um RPO (objetivo do ponto de recuperação) menor igual a 15 minutos;
4.2.35. Durante a configuração de replicação, a solução deverá indicar qual volume de dados terá replicação, permitindo, mas não se limitando, a configuração de um volume de dados com replicação síncrona e outro sem replicação habilitada, ao mesmo tempo;
4.2.36. A replicação síncrona deverá ser totalmente configurável via interface WEB;
4.2.37. Permitir, limitar a quantidade de banda utilizada para a funcionalidade de replicação assíncrona;
4.2.38. Permitir, a réplica de dados deduplicados e comprimidos para a funcionalidade de replicação assíncrona;
4.2.39. Em relação ao portal de infraestrutura como serviço, a solução deve possibilitar o provisionamento de recursos computacionais e possuir as seguintes características:
4.2.39.1. Definir repositórios externo de autenticação para usuários - Active Directory da MicrosoG;
4.2.39.2. Gerenciar catálogos de objetos (ISO ou Discos);
4.2.39.3. Criar grupos de trabalho;
4.2.39.4. Alocar recursos de CPU, memória e armazenamento por grupos de trabalho;
4.2.39.5. Definir permissões de acesso por grupo de trabalho;
4.2.39.6. Criar máquinas virtuais por grupo de trabalho;
4.2.39.7. Interagir com as máquinas virtuais conforme o grupo de trabalho;
4.2.39.8. Segregar grupos de trabalho.
4.2.40. Prover criptografia a nível de cluster ou volume de dados existentes seja via hardware ou soGware.
4.3. CARACTERÍSTICAS DO HIPERVISOR
4.3.1. Possuir licenciamento necessário para o completo atendimento da especificação técnica desse edital, na modalidade de uso perpétuo, ou seja, o hipervisor deve continuar a operar normalmente mesmo após o período de suporte e direito de atualização ativos e deverão ser fornecidos na capacidade máxima suportada pela solução integrada;
4.3.2. Permitir a criação de máquinas virtuais 32 ou 64 bits;
4.3.3. Permitir a criação de máquinas virtuais com, no mínimo, os seguintes sistemas operacionais;
4.3.3.1. MicrosoG Windows Server 2008 R2, 2012, 2012 X0, 0000;
4.3.3.2. MicrosoG Windows 7, 8, 8.1, 10;
1.3.3.3. Red Hat Enterprise Linux 6.4, 6.5, 6.6, 6.7, 6.8, 7.0, 7.1, 7.2;
1.3.3.4. Linux CentOS 6.4, 6.5, 6.6, 6.7, 6.8, 7.0, 7.1, 7.2
1.3.3.5. Linux Ubuntu Server e Desktop, 12.04.5, 14.04.x, 16.04, 12.10; 1.3.3.6. FreeBSD 9.3, 10.0, 10.1,10.2, 10.3, 11;
1.3.3.7. SUSE 11 e SUSE Linux Enterprise Server 12;
1.3.3.8. Oracle Linux 6.x, 7.x;
1.3.3.9. Debian 8.5 e 9.x.
4.3.4. Permitir a criação de novas máquinas virtuais através de interface gráfica.
4.3.5. Possibilitar que seja feita alterações de configurações (CPU, memória, disco e rede) de máquinas virtuais existentes através de interface gráfica;
4.3.6. Possibilitar adição dinâmica de CPU e memória de máquinas virtuais existentes, conforme a compatibilidade do sistema operacional;
4.3.7. Possuir interface gráfica de gerenciamento de recursos como CPU, Memória e I/O para as máquinas virtuais;
4.3.8. Possuir configuração distribuída de redes virtuais em todos os servidores do cluster;
4.3.9. Permitir que as máquinas virtuais possam utilizar diferentes redes virtuais em um mesmo servidor;
4.3.10. Capacidade de monitorar, gerenciar e alterar continuamente a utilização dos recursos de processamento representado pelo conjunto de servidores fisicos, alocando inteligentemente e redistribuindo dinamicamente as máquinas virtuais entre os servidores baseado em regras pré-definidas que reflitam as necessidades e mudanças de prioridades de cada máquina virtual;
4.3.11. Permitir a criação de ambiente de alta disponibilidade, na perspectiva do hipervisor, um cluster entre os servidores fisicos, e na indisponibilidade de um dos servidores, efetuar inteligentemente a redistribuição das máquinas virtuais entre os demais servidores, sem requerer intervenção manual;
4.3.12. Possuir recurso de virtualização de uma ou mais placas de rede, cada uma com seu próprio endereço IP e MAC address;
4.3.13. Possibilitar a criação de novas máquinas virtuais através de modelos já criados e prontos para serem instalados em qualquer sobre o virtualizador de qualquer servidor fisico que componha a solução integrada;
4.3.14. Monitorar a utilização individual de cada máquina virtual criada;
4.3.15. Possibilitar parar, iniciar, suspender e resetar máquinas virtuais;
4.3.16. Permitir criação de regras de afinidade entre máquinas virtuais e servidores do cluster, ou seja, com base em políticas pré-definidas determinadas máquinas virtuais deverão ser hospedadas somente em um conjunto determinado de servidores;
4.3.17. Permitir a criação de regras de anti-afinidade entre máquinas virtuais, ou seja, com base em políticas pré-definidas determinadas máquinas virtuais não poderão ser hospedadas no mesmo servidor do cluster;
4.3.18. Permitir a configuração de acesso não uniforme à memória RAM (vNUMA) oriundo das máquinas virtuais;
4.3.19. Permitir a entrega de placas de aceleração gráfica de modo direto (dedicado) ou partes (virtual);
4.3.20. Possuir de forma gráfica toda visibilidade fisica e lógica do ambiente de rede de dados do cluster.
4.4. REQUISITOS DE GERENCIAMENTO LOCAL E CENTRALIZADO
4.4.1. Possuir console de administração WEB em alta disponibilidade, utilizando o método de acesso HTTPS, com certificados gerados e auto-assinados ou importados de uma unidade certificadora;
4.4.2. Disponibilizar acesso ao sistema operacional da solução através do protocolo padrão SSH (Secure Shell) ou similar;
4.4.3. Ter a console WEB desenvolvida em linguagem de marcação, exemplo HTML5 ou similar;
4.4.4. Permitir integração com MicrosoG Active Directory da MicrosoG ou OpenLADP para autenticação, ou então, utilizar autenticação local;
4.4.5. Permitir automatização de processos de implementação, manutenção e gerenciamento do agrupamento de módulos através de chamadas padrões HTTP (get, post, delete, etc.) ao através interações API (Aplication Programming Interface);
4.4.6. Implementar uma interface de linha de comando completa para administração e monitoramento de os componentes do cluster, tais como:
4.4.6.1. Informar saúde dos componentes do cluster;
4.4.6.2. Criar, alterar ou deletar um novo container;
4.4.6.3. Habilitar ou desabilitar deduplicação em um disco virtual;
4.4.6.4. Parâmetros avançados do Erasure Coding;
4.4.6.5. Dentre outros.
4.4.7. Suportar autenticação de 2 (dois) níveis, permitindo a autenticação e controle de acesso através da combinação de dispositivos de segurança fisica e senhas de acesso;
4.4.8. Proporcionar maior segurança ao sistema operacional dos componentes críticos da solução através do bloqueio de acesso ao terminal de linha de comando, podendo ser habilitado e desabilitado a qualquer momento;
4.4.9. Quando necessário, a solução deverá permitir acesso externo aos dados armazenados no cluster, através de uma funcionalidade liberação a partir de um dado segmento de rede configurado pelo administrador.
4.4.10. A console WEB deve fornecer acesso à, no mínimo, as seguintes opções:
4.4.10.1. Painel principal;
4.4.10.2. Painel da saúde do Sistema (cluster);
4.4.10.3. Painel das Máquinas Virtuais;
4.4.10.4. Painel do Storage;
4.4.10.5. Painel do Hardware;
4.4.10.6. Painel de Recuperação de Desastres;
4.4.10.7. Painel de Análise de Performance;
4.4.10.8. Painel de Alertas e Eventos;
4.4.11. Deve suportar envio de alertas e eventos via SNMP.
4.4.12. Permitir a visualização de informações dos switches topo de rack na console Web de administração do cluster. A solução deverá oferecer a opção de adicionar os switches de rede, obtendo as informações através do protocolo SNMPv2c, SNMPv3 ou através de CDP. Ao menos as seguintes informações deverão estar disponíveis:
4.4.12.1. Situação dos switches;
4.4.12.2. Quantidade de portas;
4.4.12.3. Velocidade das portas;
4.4.13. Com o objetivo de facilitar o monitoramento e visualização das informações do cluster, ao menos as seguintes informações deverão estar disponíveis no cluster:
4.4.13.1. Sumário do hipervisor;
4.4.13.2. Sumário do hardware;
4.4.13.3. IOPS do cluster;
4.4.13.4. Utilização de banda do cluster;
4.4.13.5. Latência do cluster;
4.4.13.6. Situação da resiliência dos dados;
4.4.13.7. Alertas e eventos.
4.4.14. Deverão estar disponíveis os seguintes tipos de usuários e suas respectivas funções:
4.4.14.1. Visualização - Não permite nenhuma alteração na configuração;
4.4.14.2. Administração do cluster - Pode realizar todas as operações disponíveis, exceto criar ou modificar os usuários;
4.4.14.3. Usuário administrativo - Pode realizar todas as operações disponíveis.
4.4.15. Disponibilizar ferramenta de gerenciamento unificada, para facilitar as tarefas de administração diária e permitir a orquestração de sites em cenários de indisponibilidade planejados ou não;
4.4.16. Apresentar no mínimo as seguintes informações consolidadas de todas as entidades registradas:
4.4.16.1. Saúde dos Sistema clusters;
4.4.16.2. Máquinas Virtuais;
4.4.16.3. Armazenamento;
4.4.16.4. Situação do Hardware;
4.4.16.5. Painel de Análise de Performance;
4.4.16.6. Painel de Alertas e Eventos;
4.4.17. Permitir no mínimo a orquestração das rotinas de:
4.4.17.1. Inicialização ordenada das entidades protegidas;
4.4.17.2. Temporização entre as entidades protegidas;
4.4.17.3. Automação dos planos de recuperação no site remoto previamente definido;
4.4.17.4. Automação dos planos recuperação no site original previamente definido;
4.4.17.5. Validação dos planos recuperação;
4.4.17.6. Criação de replicas automáticas e manuais.
4.4.18. A interface IPMI ou similar presente em cada um dos servidores deverá ser baseada em Web, acessível através de um endereço IP. No mínimo as seguintes opções deverão estar disponíveis na interface Web:
4.4.18.1. Configuração remota do BIOS;
4.4.18.2. Console remoto gráfico;
4.4.18.3. Ligar, desligar e reiniciar o servidor remotamente;
4.4.18.4. Monitoramento do Hardware;
4.4.18.5. Atualização do soGware IPMI ou similar através da interface Web.
4.4.19. Suportar o envio periódico de informações e estatisticas automaticamente para o suporte do fabricante, funcionalidade conhecida como análise proativa de otimização e detecção antecipada de problemas;
4.4.20. Permitir o registro automática de incidentes nos fabricantes, caso algum componente que cause paralisação ou degradação da solução apresente problema;
4.4.21. Disponibilizar, quando necessário, o acesso remoto a equipe de suporte do fabricante através de túnel criptografado com o objetivo de permitir manutenções ou análise a problemas. Permitir desabilitar este recurso a qualquer momento através da interface WEB.
Tabela 1 - Modelos
Descrição | Quant. | Total de núcleos | Memória RAM (GB) | Volumetria total discos SSD (GB) | Volumetria total discos rígidos (TB) |
Servidor 1 5 36 | 512 | 3840 | 40 | ||
Servidor 3 | 4 | 20 | 256 | 1920 | 16 |
4.5. SERVIDOR TIPO 1 HIPERCONVERGENTE
4.5.1. Os Servidores Tipo 1 poderão ser instalados um chassi modular ou unidade única com no máximo 2 (duas) unidades de rack de altura (2U);
4.5.2. Cada chassi deverá conter 2 (duas) fontes de alimentação redundantes do tipo hot-swap, sendo que, na ocorrência de falha de uma delas, o sistema deverá permanecer funcionando em plena capacidade. A fonte de alimentação deverá ter a seguinte especificação:
4.5.2.1. 2.2 kW de saída em 200-240v no máximo;
4.5.2.2. Certificação 80 Plus de eficiência ou similar.
4.5.3. Atender as seguintes especificações:
4.5.3.1. Se instalado em um chassi modular deverá ser do tipo hot-pluggable;
4.5.3.2. Possuir 2 (dois) processadores fisicos padrão x86, no mínimo Intel Server Xeon Gold. Cada processador deve possuir capacidade de, no mínimo, 18 (dezoito) cores fisicos, 36 (trinta e seis) threads, mínimo 24 MB (vinte e quatro megabytes) de cache L3, suportar conjunto de instrução de 64-bits (sessenta e quatro bits), AVX, AVX2 e AVX-512, frequência baseada em processador de 2,3 GHz (dois vírgula três gigahertz) e frequência turbo máxima de 3,7 GHz (três vírgula sete gigahertz). Especificação dos processadores conforme tabela de modelos;
4.5.3.3. Suportar no mínimo 768 GB de memória RAM DDR4 ECC. A quantidade de memória RAM conforme tabela de modelos;
4.5.3.4. Possuir no mínimo 2 (dois) discos de estado sólido (SSD) padrão SATA de 6.0 Gb/s e hot-swap. Volumetria dos discos SSD conforme tabela de modelos;
4.5.3.5. Possuir no mínimo 4 (quatro) discos padrão SATA de 6 Gb/s e hot-swap; Volumetria dos discos rígidos conforme tabela de modelos;
4.5.3.6. Possuir 2 (duas) portas Gigabit Ethernet padrão 1000Base-T, LAN1 e LAN2;
4.5.3.7. Possuir ao menos 2 (duas) portas SFP+;
4.5.3.8. Possuir uma porta Gigabit Ethernet padrão 1000Base-T dedicada ao módulo de gerenciamento IPMI ou similar;
4.5.3.9. Possuir uma porta VGA;
4.5.3.10. Possuir duas portas USB 3.0;
4.5.3.11. Uma das portas Gigabit Ethernet para comunicação com a rede externa, deverá funcionar como redundância da porta IPMI dedicada ou similar, permitindo o acesso aos recursos IPMI em caso de falhas na comunicação com a porta IPMI dedicada;
4.5.3.12. No painel frontal do chassi, as seguintes funcionalidades e/ou luzes indicativos deverão estar presentes:
4.5.3.12.1. Botão de energia com sinalizador integrado para cada um dos servidores; 1.5.3.12.2. Botão identificação frontal e traseiro para identificação, por servidor; 1.5.3.12.3. Para determinar atividade ou falha dos discos SSD e discos rígidos; 1.5.3.12.4. Para determinar atividade das interfaces Gigabit Ethernet LAN1 ou LAN2;
1.5.3.12.5. Para indicar de alertas como: superaquecimento do equipamento, falhas nas ventoinhas e fonte de alimentação.
4.5.3.13. Possuir módulo de alta disponibilidade para instalação do soGware hipervisor, com tecnologia de memória flash, integrado à placa mãe de cada um dos servidores ou em barramento específico, com capacidade bruta de, no mínimo, 200 GB (duzentos gigabytes);
4.5.4. Ser fornecido com todos os acessórios necessários para sua instalação, incluindo, mas não se limitando, a trilhos para montagem em rack e cabos de alimentação elétrica;
4.5.5. A solução deverá ser certificada pelo INMETRO ou correspondente.
4.6. SERVIDOR TIPO 3 HIPERCONVERGENTE
4.6.1. Os Servidores Tipo 3 poderão ser instalados um chassi modular ou unidade única com no máximo 2 (duas) unidades de rack de altura (2U);
4.6.2. Cada chassi deverá conter 2 (duas) fontes de alimentação redundantes do tipo hot-swap, sendo que, na ocorrência de falha de uma delas, o sistema deverá permanecer funcionando em plena capacidade. A fonte de alimentação deverá ter a seguinte especificação:
4.6.2.1. 2.2 kW de saída em 200-240v no máximo;
4.6.2.2. Certificação 80 Plus de eficiência ou similar.
4.6.3. Atender as seguintes especificações:
4.6.3.1. Se instalado em um chassi modular deverá ser do tipo hot-pluggable;
4.6.3.2. Possuir 2 (dois) processadores fisicos padrão x86, no mínimo Intel Server Xeon Silver. Cada processador deve possuir capacidade de, no mínimo, 10 (dez) cores fisicos, 20 (vinte) threads, mínimo 13 MB (treze megabytes) de cache L3, suportar conjunto de instrução de 64-bits (sessenta e quatro bits), AVX,
AVX2 e AVX-512, frequência baseada em processador de 2,2 GHz (um vírgula oito gigahertz) e frequência turbo máxima de 3,0 GHz (três gigahertz). Especificação dos processadores conforme tabela de modelos;
4.6.3.3. Suportar no mínimo 512 GB de memória RAM DDR4 ECC. A quantidade de memória RAM conforme tabela de modelos;
4.6.3.4. Possuir no mínimo 1 (um) disco de estado sólido (SSD) padrão SATA de 6.0 Gb/s e hot-swap. Volumetria dos discos SSD conforme tabela de modelos;
4.6.3.5. Possuir no mínimo 2 (dois) discos padrão SATA de 6 Gb/s e hot-swap; Volumetria dos discos rígidos conforme tabela de modelos;
4.6.3.6. Possuir 2 (duas) portas Gigabit Ethernet padrão 1000Base-T, LAN1 e LAN2;
4.6.3.7. Possuir ao menos 2 (duas) portas SFP+;
4.6.3.8. Possuir uma porta Gigabit Ethernet padrão 1000Base-T dedicada ao módulo de gerenciamento IPMI ou similar;
4.6.3.9. Possuir uma porta VGA;
4.6.3.10. Possuir duas portas USB 3.0;
4.6.3.11. Uma das portas Gigabit Ethernet para comunicação com a rede externa, deverá funcionar como redundância da porta IPMI dedicada ou similar, permitindo o acesso aos recursos IPMI em caso de falhas na comunicação com a porta IPMI dedicada;
4.6.3.12. No painel frontal do chassi, as seguintes funcionalidades e/ou luzes indicativos deverão estar presentes:
1.7.3.12.1 Botão de energia com sinalizador integrado para cada um dos servidores;
1.7.3.12.2 Botão identificação frontal e traseiro para identificação, por servidor;
1.7.3.12.3 Para determinar atividade ou falha dos discos SSD e discos rígidos;
1.7.3.12.4 Para determinar atividade das interfaces Gigabit Ethernet LAN1 ou LAN2;
1.7.3.12.5 Para indicar de alertas como: superaquecimento do equipamento, falhas nas ventoinhas e fonte de alimentação.
4.6.3.13. Possuir módulo de alta disponibilidade para instalação do soGware hipervisor, com tecnologia de memória flash, integrado à placa mãe de cada um dos servidores ou em barramento específico, com capacidade bruta de, no mínimo, 200 GB (duzentos gigabytes);
4.6.4. Ser fornecido com todos os acessórios necessários para sua instalação, incluindo, mas não se limitando, a trilhos para montagem em rack e cabos de alimentação elétrica;
4.6.5. Ser certificada pelo INMETRO ou correspondente.
4.7. REQUISITOS DE PROTEÇÃO DE DADOS
4.7.1 Possuir no mínimo as seguintes características:
4.7.1.1. Ser nativo ou de terceiros;
4.7.1.2. Ser homologado para solução modular hiperconvergente virtualizador e sistema de armazenamento distribuído;
4.7.1.3. Não poderá ter limites de proteção e recuperação de máquinas virtuais;
4.7.1.4. Todas as funcionalidades suportadas pela solução modular hiperconvergente e virtualizador devem estar habilitadas;
4.7.1.5. Estar habilitada para permitir a instalação de quantos servidores de movimentação de dados e de gerência da solução, quanto forem necessários para configuração do ambiente a ser protegido, de acordo com as melhores práticas propostas pelo fabricante;
4.7.1.6. Ser a última versão disponível, não será aceita a utilização de versões anteriores para cobrir algum item desse descritivo técnico;
4.7.1.7. Mostrar na console de gerenciamento a quantidade de licenças adquiridas e utilizadas;
4.7.1.8. Caso a solução ofertada necessite de algum banco de dados, o mesmo deverá ser fornecido devidamente licenciado sem nenhum custo extra.
4.8. INFRAESTRUTURA
4.8.1 Deve possuir arquitetura em múltiplas camadas ou arquitetura similar:
4.8.1.1. servidor de gerência de proteção;
4.8.1.2. servidores de movimentação de dados;
4.8.1.3. clientes ou agentes de backup.
4.8.2 O servidor de gerência de proteção deverá ter suporte para instalação no mínimo com os sistemas operacionais abaixo:
4.8.2.1. MicrosoG Windows 2012;
4.8.2.2. Windows 2016.
4.8.3 O servidor de movimentação de dados deverá ter suporte para instalação no mínimo com os sistemas abaixo:
4.8.3.1. MicrosoG Windows 2012;
4.8.3.2. MicrosoG Windows 2016;
4.8.3.3. Oracle Linux 6.x ou 7.x;
4.8.3.4. Red Hat Enterprise Linux 6.x ou 7.x.
4.8.4. Possuir um banco de dados ou catálogo interno, contendo informações sobre todos os arquivos e mídias onde os backups foram armazenados;
4.8.5. Caso a ferramenta faça uso de um soGware de banco de dados para armazenamento das informações, e este requeira uma licença para uso, essa licença deve ser fornecida em conjunto com a solução;
4.8.6. Ser flexível e escalável, permitindo sua instalação, configuração e uso em sites remotos interligados ao site principal através de WAN. Além disso, a solução deve prover recursos de desduplicação na origem, desduplicação no destino, e compactação tanto no site principal como nos sites remotos na inteireza da capacidade previamente licenciada e sem necessidade de aquisição de qualquer outro tipo de licença ou recurso adicional para execução de tais operações;
4.8.7. Ter a funcionalidade para proteger localidades remotas, assegurando que a transmissão de dados através da WAN seja minimizada, provendo tanto desduplicação quanto replicação, enquanto possibilita recuperação granular de dados. A solução deve prover arquitetura flexível ao ponto de que a recuperação no escritório regional possa ser total (com todos os dados vindos do datacenter) ou parcial (com somente o envio dos dados que não estão em cache local);
4.8.8. Permitir o controle da banda utilizada durante a operação de cópia de proteção.
4.9. FUNCIONALIDADES DE CÓPIA E RECUPERAÇÃO
4.9.1. Ser capaz de realizar cópia de arquivos abertos sem que a consistência dos mesmos seja comprometida;
4.9.2. Possuir a opção de priorização de tarefas de proteção com opção de resumo da cópia caso uma atividade de menor prioridade seja colocada em estado de espera por uma tarefa de maior prioridade;
4.9.3. Possuir a funcionalidade de paralelizar a gravação dos dados em dispositivos de armazenamento (funcionalidade conhecida como multiplexação);
4.9.4. Ser capaz de enviar alertas através de e-mail com o objetivo de reportar eventos ocorridos na operação e configuração da solução
4.9.5. Ser capaz de enviar traps SNMP (Simple Network Management Protocol) com o objetivo de reportar eventos ocorridos na operação da solução;
4.9.6. Possuir a funcionalidade de agendamento automático de tarefas de cópia;
4.9.7. Para operações de dados gravadas em disco e fita, a solução de proteção deve possuir as seguintes funcionalidades:
4.9.7.1. Para um mesmo dado armazenado deve haver a possibilidade de configuração de diferentes períodos de retenção;
4.9.7.2. Para um dado armazenado deve haver a possibilidade de estender o período de retenção.
4.9.8. Implementar a execução de cópias completas sintéticas ou similar. Uma cópia completa sintética é gerada através de uma outra cópia completa tradicional (não sintetizado) anterior e de cópias diferenciais subsequentes ou de um backup incremental cumulativo. A cópia sintetizada deverá ser capaz de restaurar arquivos e diretórios da mesma maneira que um cliente faz a restauração de uma cópia tradicional;
4.9.9. Permitir a gravação de cópias do tipo Disco-Para-Disco-Para-Unidade de Fita;
4.9.10. Permitir cópias diretamente para a unidade de fita sem a necessidade de armazenar primeiramente em disco;
4.9.11. Ser compativél com bibliotecas auto-carregadoras de cartuchos de fitas magnéticas;
4.9.12. Possuir a funcionalidade de criar múltiplas cópias de backups armazenados, com a opção de recuperação dos dados de forma automática através da cópia secundária se a cópia primária não estiver mais disponível.
4.10. FUNCIONALIDADES DA CONSOLE DE GERENCIAMENTO, INTEGRAÇÃO E ALTA-DISPONIBILIDADE
4.10.1. Possuir interface única, que seja capaz de gerenciar e executar operações de proteção e recuperação dos sistemas operacionais Windows, Unix e Linux; ambiente de virtualização Acropolis Operating System; aplicações, MicrosoG Active Directory e banco de dados MicrosoG SQL Server, Oracle (Windows e Linux) e Oracle RAC (em Linux);
4.10.2. O acesso administrativo ao console do servidor de gerenciamento da solução poderá ser feito através de ferramenta disponibilizada no próprio soGware (console gráfico) ou através de navegador Web;
4.10.3. Implementar configuração de serviços com redundância para promover alta-disponibilidade dos serviços de gerenciamento;
4.10.4. Implementar distribuição automática de carga entre os movimentadores de dados, ou seja, os dados oriundos dos clientes de backup deverão ser distribuídos de forma automática entre os servidores de cópia, e em caso de falha de um dos servidores, o cliente automaticamente irá encaminhar seus dados para o outro servidor de cópia ativo. Esta funcionalidade deverá ser nativa do produto, e não pode ser construída com o uso de soluções baseadas em soGwares de cluster de terceiros.;
4.10.5. Suportar unificação de autenticação (single sign-on - SSO), permitindo a integração com o MicrosoG Active Directory. A funcionalidade de integração com o Active Directory deverá permitir a definição granular das permissões administrativas aos recursos, objetos e servidores definidos na configuração do soGware;
4.10.6. A base de dados para armazenamento do catálogo deverá possuir mecanismo de proteção (backup) das informações armazenadas no catálogo e funcionalidades de recuperação rápida do catálogo em caso de desastre;
4.11. SUPORTE À CRIPTOGRAFIA
4.11.1. Implementar criptografia de dados na origem (cliente de backup), de uma forma que seja garantido que o dado que trafegará na rede local ou na rede WAN seja criptografado;
4.11.2. Implementar criptografia de dados no destino do backup, de uma forma que seja garantido que os dados sejam criptografados;
4.11.3. Deverá implementar no mínimo chaves de criptografia de 128 bits e 256 bits.
4.12. INTEGRAÇÃO COM AS SEGUINTES APLICAÇÕES PARA CÓPIA E RESTAURAÇÃO
4.12.1. Realizar proteção e recuperação dos seguintes sistemas operacionais, aplicações, banco de dados e virtualizadores:
1.13.1.1. MicrosoG Windows Server XP, 7, Vista, 8, 10, 2008, 2008 R2, 2012, 2012 R2 e 2016;
1.13.1.2. Oracle Linux 5.x, 6.x e 7x;
1.13.1.3. Red Hat Enterprise Linux 5.x,6.x e 7.x; 1.13.1.4. Ubuntu 12.x, 13.x,14.x,15.x,16.x,17.x,18.x;
1.13.1.5. Debian 5.x, 6.x, 7.x, 8.x, 9.x;
1.13.1.6. MicrosoG Active Directory 2008, 2012, 2016 e 2019;
1.13.1.7. MicrosoG SQL Server 2005, 2008 R2, 2012, 2014, 2016 e 2017;
1.13.1.8. Oracle 10.2.x, 11g, 12c, 18c (Linux ou Windows);
1.13.1.9. Oracle RAC 10g, 11g, 12c e 18c (em Linux); 1.13.1.10. MySQL 5.1.x, 5.5.x, 5.6.x e 5.7.x;
1.13.1.11. Maria DB 5.5.x, 10.0.x e 10.2.x;
1.13.1.12. PostgreSQL 9.2 ou superior;
1.13.1.13. Nutanix AHV 5.5.X, 5.9.X, 5.10.X ou superior.
4.13. SUPORTE AO ACTIVE DIRECTORY
4.13.1. Executar cópia em tempo de execução do MicrosoG Active Directory;
4.13.2. Possibilitar as seguintes opções de recuperação:
4.13.2.1. recuperação de um objeto;
4.13.2.2. recuperação de um atributo;
4.13.2.3. recuperação de um atributo de um objeto deletado.
4.14. SUPORTE A ORACLE E ORACLE RAC
4.14.1. Deverá executar proteção e recuperação de base da dados Oracle e Oracle RAC com as seguintes características nativas sem a necessidade de criação de scripts:
4.14.1.1. proteção e recuperação das bases de dados do Oracle/Oracle RAC via RMAN e sem parada do banco;
4.14.1.2. arquivamento do registro de eventos (log) possibilitando a criação de rotina de cópia para que ocorra com intervalos de 1 (uma) hora;
4.14.1.3. arquivamento de transações (archives logs) baseados na quantidade de arquivamento (archives);
4.14.1.4. configuração que após a cópia dos registros de transações (archives logs) os mesmos sejam mantidos ou deletados;
4.14.1.5. proteção do Banco, a solução deverá proteger a área de catálogo, control file e sp file.
4.14.2. Possibilitar a recuperação com as seguintes características:
4.14.2.1. Recuperação completa da Base de dados no mesmo servidor;
4.14.2.2. Recuperação completa da Base de dados em outro servidor;
4.14.2.3. Recuperação de um datafile específico;
4.14.2.4. Recuperação granular no nível de tabela;
4.14.2.5. Recuperação em um momento do tempo específico.
4.15. SUPORTE A MICROSOFT SQL SERVER
4.15.1. Executar proteção e recuperação de base da dados MicrosoG SQL Server com as seguintes características nativas sem a necessidade de criação de scripts:
4.15.1.1. proteção e recuperação de bases de dados MicrosoG SQL Server sem parada do banco;
4.15.1.2. cópia de registro de transações (transaction log) possibilitando a criação de rotina de cópia para que ocorra com intervalos de 1 (uma) hora;
4.15.1.3. configuração que após a cópia dos registros de transações (transaction log) os mesmos sejam mantidos ou deletados;
4.15.2. Possibilitar a recuperação com as seguintes características:
4.15.2.1. Recuperação completa da base de dados no mesmo servidor;
4.15.2.2. Recuperação completa da base de dados em outro servidor;
4.15.2.3. Recuperação de uma base específica;
4.15.2.4. Recuperação em um momento do tempo específico.
4.16. SUPORTE A POSTGRESQL
4.16.1. Executar proteção e recuperação de base da dados PostgreSQL Server com as seguintes características nativas sem a necessidade de criação de scripts:
4.16.1.1. Cópia em tempo de execução do banco de dados seja do tipo Dump e Logs;
4.16.1.2. Permitir a recuperação completa e a nível de Logs;
4.16.1.3. Restaurar a base de dados em um ponto no tempo;
4.16.1.4. Restaurar uma tabela do banco de dados;
4.16.1.5. Restaurar a base de dados no mesmo servidor em caminho diferente;
4.16.1.6. Restaurar uma instância em um outro servidor.
4.17. SUPORTE A MYSQL
4.17.1. Executar proteção e recuperação de base da dados MySQL Server com as seguintes características nativas sem a necessidade de criação de scripts:
4.17.1.1. Cópia em tempo de execução do banco de dados seja do tipo Dump ou Logs;
4.17.1.2. Permitir a recuperação completa e a nível de Logs;
4.17.1.3. Restaurar a base de dados em um ponto no tempo;
4.17.1.4. Restaurar a base de dados no mesmo servidor na mesma instância ou em uma instância diferente;
4.17.1.5. Restaurar uma instância em um outro servidor;
4.17.1.6. Permitir agendar uma recuperação.
4.18. SUPORTE A VIRTUALIZAÇÃO
4.18.1. Executar proteção e recuperação do Ambiente Virtual com as seguintes características:
4.18.1.1. Realizar recuperação da imagem completa da máquina virtual (Acropolis Hypervisor) e também de arquivos de maneira granular sem a necessidade de scripts, área temporário ou montagem dos arquivos RAW;
4.18.1.2. No caso da restauração granular, não há necessidade de se restaurar a Guest VM inteira;
4.18.1.3. Permitir redirecionar a restauração de uma máquina virtual hospedada para uma pasta alternativa, outro volume de armazenamento, servidor ou rede;
4.18.1.4. Incluir automaticamente máquinas virtuais novas criadas dentro de seleções de cópias anteriores;
4.18.1.5. Permitir o backup completo (Full), incremental e sintético para os servidores virtuais;
4.18.1.6. Ser capaz de realizar cópias e restauração de servidores virtuais Linux e Windows, sejam elas estado de consistência ou aplicação;
4.18.1.7. Permitir que as tarefas de cópias e restauração sejam realizadas via interface gráfica, sem a necessidade de scripts;
4.18.1.8. Ser armazenado de maneira desduplicadas;
4.18.1.9. Estar integrada à solução de cópias de baixo nível da camada de armazenamento (Snapshot).
4.19. FUNCIONALIDADE DE DESDUPLICAÇÃO DE CÓPIA
4.19.1. Permitir uso da tecnologia de desduplicação de dados para toda a capacidade e processadores licenciados, eliminando blocos repetidos, para cópias e arquivamento em disco e movimentação de dados desduplicados, independente de quantitativo de dispositivos de armazenamento que compõem a infraestrutura da CONTRATANTE.
4.19.2. Implementar desduplicação a nível de blocos, não sendo aceita a técnica de Single-Instance Storage;
4.19.3. Implementar desduplicação de blocos na origem (client-side desduplication), de forma que o cliente envie apenas novos blocos de dados criados e/ou modificados a partir da última cópia total completa;
4.19.4. Implementar desduplicação de dados nos servidores de armazenamento (target desduplication), de forma que tais servidores tratem adequadamente blocos repetidos enviados pelos clientes, evitando assim o armazenamento de blocos redundantes;
4.19.5. Implementar desduplicação de dados global, efetuando o backup de determinado arquivo apenas uma vez, independente do site e ou localidade originários. A desduplicação global deverá ocorrer em uma única área de armazenamento;
4.19.6. Implementar desduplicação de dados em tarefas de cópia;
4.19.7. Implementar desduplicação e compressão em uma mesma tarefa;
4.19.8. Implementar desduplicação de dados em tarefas de arquivamento;
4.19.9. Permitir a restauração granular de arquivos ou sistemas de arquivos a partir de cópias em disco ou fita. Em caso de backup armazenado em disco a recuperação granular poderá ser feito utilizando-se cópias que possam estar desduplicados;
4.19.10. Suportar desduplicação global onde mais de um movimentador de dados acesse e armazene blocos únicos na mesma base de desduplicação;
4.19.11. Cada movimentador de dados deverá gerenciar no mínimo 150 TB de dados desduplicados;
4.19.12. Caso a solução ofertada não atenda a especificação dos itens 4.19.9 e 4.19.10 via software, a CONTRATADA deverá oferecer uma solução baseada em appliance.
4.20. RELATÓRIOS E ALERTAS
4.20.1. Vir disponível com os seguintes relatórios e reportes:
4.20.1.1. quantidade de rotinas de backup concluídos nas últimas 24 horas, nos últimos 30 dias e nos últimos 6 meses;
4.20.1.2. quantidade de recuperações efetuadas nas últimas 24 horas, nos últimos 30 dias e nos últimos 6 meses;
4.20.1.3. resumo de rotinas de backup concluídos com sucesso, com erro ou não concluídos;
4.20.1.4. taxa de desduplicação por rotina de backup;
4.20.1.5. analise e tendência a longo prazo e análise para melhor prever o consumo de armazenamento de backup ao acompanhar as taxas de crescimento ao longo do tempo, incluindo pré e pós-desduplicação, para um acompanhamento de ROI mais fácil e taxas de desduplicação;
4.20.1.6. capaz de classificar arquivos por tipo, tamanho e idade;
4.20.1.7. mostrar o total de licenças adquiridas e o total de licenças utilizadas e caso ocorra uma nova aquisição de licenças as novas licenças deverão constar nesse relatório;
4.20.1.8. Enviar os seguintes alertas via e-mail:
1.21.1.8.1 Rotina de backup finalizada com sucesso;
1.21.1.8.2 Rotina de backup finalizada com erro
1.21.1.8.3 Rotina de backup com problema;
1.21.1.8.4 Falta de recursos para cópia – Disco ou fita;
1.21.1.8.5 Alerta para utilização de licenciamento;
1.21.1.8.6 Alerta para utilização de licenciamento acima de um volume pré-determinado.
4.21. CÓPIAS DE BAIXO NÍVEL (SNAPSHOT)
4.21.1. Possuir integração com a funcionalidade de cópias de baixo nível (snapshot) dos subsistemas de armazenamento em disco permitindo:
4.21.1.1. gerenciamento de cópias;
4.21.1.2. registro de cópias na base relacional de catálogos de forma que possa realizar buscas por elas;
4.21.1.3. controle do período pelo qual as cópias serão válidas, realizando a expiração automática de uma dela assim que o período de retenção configurado seja atingido;
4.21.2. A integração com as cópias deverá ser feita via serviço WEB (API), ou seja, não será aceito implementação de scripts manuais de pré e pós backup para esta funcionalidade;
4.21.3. Efetuar cópias criadas para disco com desduplicação;
4.21.4. Possuir integração via requisições HTTP via API (Aplication Programming Interface), para gerência de cópias (snapshots) na solução hiperconvergente Nutanix.
4.22. REQUISITOS DE CAPACITAÇÃO E INSTALAÇÃO ASSISTIDA
4.22.1. Repasse de conhecimento abrangendo configuração, segurança, disponibilidade e melhores práticas na operação dos equipamentos e soGwares adquiridos;
4.22.2. O repasse de conhecimento deverá ser realizado nas seguintes condições:
4.22.2.1. Nas dependências da Secretaria de Estado da Educação – SEDUC em conformidade com o item 5.3, em data e horários previamente acordados entre as partes;
4.22.2.2. Ministrado no período mínimo de 20 horas, incluindo teoria e laboratórios;
4.22.2.3. O repasse deverá ser feito para até 08 participantes;
4.22.3. Considerar, para efeitos de treinamento, no mínimo, os seguintes componentes da solução:
4.22.3.1. Configuração, operação e gerenciamento dos equipamentos;
4.22.3.2. Configuração e operação do soGware de armazenamento definido por soGware;
4.22.3.3. Configuração e operação do ambiente de gestão centralizada;
4.22.3.4. Procedimentos de recuperação, com retirada e inserção de novos servidores à solução;
4.22.3.5. Rotinas e operação de proteção dados;
4.22.3.6. Resolução de problemas de proteção de dados.
4.22.4. A ementa do curso deverá ser proposta pela CONTRATADA e enviada com antecedência ao início do repasse;
4.22.5. Os materiais de apoio poderão ser em português ou inglês, sendo impressões ou digitais;
4.22.6. A ementa citada no subitem anterior deverá ser aceita pela CONTRATANTE, podendo ela também sugerir inclusão ou exclusão de algum tópico;
4.22.7. Havendo necessidade deverão ser utilizados equipamentos similares aos adquiridos. Sendo possível poderão ser utilizados os próprios equipamentos adquiridos;
4.22.8. Ser realizado por profissional que tenha qualificação técnica necessária quanto à instalação, configuração e gerenciamento da solução adquirida;
4.22.9. Ser do tipo serviço profissional executado pelo fabricante ou parceiro devidamente credenciado;
4.22.10. Durante o período pré-instalação deve ser apresentado um plano de atividade contento: o descritivo do projeto, cronograma de execução, pré-requisitos, comunicação e outros;
4.22.11. Prever a migração de no mínimo 20 máquinas virtuais por servidor;
4.22.12. Instalar dentro das boas práticas de cada fabricante.
Item | Quantidade | Descrição |
Switch 2 | 2 | 32 (trinta e duas) portas 1/10 Gbe compativeis SFPs |
Módulo 1 | 4 | Módulo tipo 1 – GBIC SFP 1 Gbe |
Módulo 2 | 4 | Módulo tipo 2 – GBIC SFP+ 10 Gbe SR |
4.23. SWITCH 2
4.23.1. REQUISITOS GERAIS
4.23.1.1. Ser composta de no mínimo dois equipamentos em alta disponibilidade, montável em rack 19” de no mínimo 70 cm de profundidade, devendo vir acompanhado dos acessórios necessários para sua devida fixação;
4.23.1.2. Conter a descrição detalhada com códigos do fabricante de todos os módulos, fontes e acessórios fornecido;
4.23.1.3. Possuir fonte de alimentação AC interna que trabalhe em 100V-240V, 50/60 Hz, com detecção automática de tensão e frequência, e hot-swappable;
4.23.1.4. Possuir fonte de alimentação AC redundante interna, hot-swappable;
4.23.1.5. Possuir bandeja de ventiladores substituível em campo (field replaceable);
4.23.1.6. Possuir ventilação "front-to-back", ou seja, a saída de ar quente deve acontecer pela traseira do equipamento;
4.23.1.7. Possuir capacidade agregada de switching de, no mínimo, 320 (trezentos e vinte) Gbps;
4.23.1.8. Possuir capacidade de encaminhamentos de pacotes, de no mínimo 230 (duzentos e trinta) Mpps utilizando pacotes de 64 bytes;
4.23.1.9. A Memória Flash instalada deve ser suficiente para comportar no mínimo duas imagens do Sistema Operacional simultaneamente, permitindo que seja feito um upgrade de SoGware e a imagem anterior seja mantida;
4.23.1.10. Todas as interfaces ofertadas devem ser non-blocking;
4.23.1.11. Possuir latência média de, no máximo, 900 (novecentos) nanossegundos para pacotes de 64 bytes em interfaces SFP+;
4.23.1.12. Possuir homologação da ANATEL, de acordo com a Resolução número 242.
4.23.2. INTERFACES
4.23.2.1. Possuir porta de console com conector RJ-45 ou DB9 macho;
4.23.2.2. Possuir leds indicativos de funcionamento da fonte de alimentação, ventiladores e status das portas;
4.23.2.3. Possuir 16 portas 100Mb/1G/10GBASE-X ativas simultaneamente, baseadas em SFP/SFP+, devendo um mesmo slot suportar interfaces 10 Gigabit Ethernet 10GBASE-SR, 10GBASE-LR, 10GBASE-CR, 10GBASE-ER e 10GBASE-ZR. Essas interfaces deverão suportar a utilização de mini-GBICs (SFPs) Gigabit Ethernet 1000Base-SX, 1000Base-LX (10KM) e 1000Base-ZX (70Km) e suportar a utilização de mini-GBICs (SFPs) Fast Ethernet 100Base-FX. Não é permitida a utilização de conversores externos. Ser entregue com no mínimo 02 (dois) cabos do tipo Direct Attached Cable – DAC de pelo menos de 1 (um) metro;
4.23.2.4. Todas as interfaces 1/10 Gigabit Ethernet acima devem funcionar simultaneamente;
4.23.2.5. O equipamento deve possuir além das portas acima citadas uma porta adicional 10/100/1000 com conector RJ-45 para gerência out-of-band do equipamento;
4.23.2.6. Permitir empilhamento de no mínimo oito equipamentos e gerência através de um único endereço IP;
4.23.2.7. O equipamento deve implementar empilhamento através de duas portas 10GBASE-X SFP+, solicitadas anteriormente;
4.23.2.8. O equipamento deve suportar o agrupamento lógico (gerência por um único IP) de unidades remotamente instaladas (no mínimo 10km);
4.23.2.9. O empilhamento deve possuir arquitetura de anel para prover resiliência;
4.23.2.10. O empilhamento deve permitir a criação de grupos de links agregados entre diferentes membros da pilha, segundo 802.3ad;
4.23.2.11. O empilhamento deve suportar espelhamento de tráfego entre diferentes unidades da pilha;
4.23.2.12. Ser possível mesclar em uma mesma pilha equipamentos que possuam portas de acesso 10/100/1000 e equipamentos que implementem PoE.
4.23.3. FUNÇÕES DE CAMADA 2
4.23.3.1. Armazenar, no mínimo, 16.000 (dezesseis mil) endereços MAC;
4.23.3.2. Implementar agregação de links conforme padrão IEEE 802.3ad com suporte a LACP;
4.23.3.3. Em conjunto com outro equipamento de mesmo modelo, deverá permitir que um switch conectado aos dois, tenha a possibilidade de agregação de links (IEEE 802.3ad) com suporte a LACP com os mesmos, de forma a simular a existência de apenas um único link lógico entre este equipamento e os dois switches do modelo aqui especificado (Por exemplo: Fabric, vPC, vLAG, Multi-Chassis Trunking). O único link lógico entre as camadas deve eliminar convergência do Spanning Tree, possibilitando o tráfego simultâneo por mais de uma conexão;
4.23.3.4. Implementar jumbo frames em todas as portas ofertadas, com suporte a pacotes de até 9216 Bytes;
4.23.3.5. Implementar Proxy-ARP (RFC 1027);
4.23.3.6. Implementar IGMP v1, v2 e v3 Snooping;
4.23.3.7. Implementar IGMPv1 (RFC 1112), IGMP v2 (RFC 2236) e IGMPv3 (RFC 3376);
4.23.3.8. Implementar MVR (Multicast VLAN Registration);
4.23.3.9. Implementar DHCP/Bootp relay configurável por VLAN para IPv4 e IPv6;
4.23.3.10. Implementar servidor DHCP interno que permita a configuração de um intervalo de endereços IP a serem atribuídos os clientes DHCP e possibilite ainda a atribuição de, no mínimo, default-gateway, servidor DNS e servidor WINS;
4.23.3.11. Implementar DHCP Option 82, de acordo com a RFC 3046, com identificação de porta e VLAN, configurável por VLAN;
4.23.3.12. Implementar DHCP Client para IPv4 e IPv6;
4.23.3.13. Implementar RFC 3021 - Using 31-Bit Prefixes on IPv4 Point-to-Point Links;
4.23.3.14. Implementar Spanning-Tree (IEEE 802.1d), Rapid Spanning Tree (IEEE 802.1w), Multiple Instance STP (802.1s) e PVST+;
4.23.3.15. Implementar a configuração de Multiple Spanning Tree Protocol, com suporte a, pelo menos, 64 domínios;
4.23.3.16. Implementar funcionalidade vinculada ao spanning-tree onde é possível designar portas de acesso (por exemplo onde estações estão conectadas) que não sofram o processo de Listening-Learning, passando direto para o estado de Forwarding. No entanto, as portas configuradas com esta funcionalidade devem detectar loops na rede normalmente;
4.23.3.17. Implementar funcionalidade vinculada ao spanning-tree que evite a eleição de outros switches da rede como Root;
4.23.3.18. Implementar funcionalidade vinculada ao spanning-tree que permita desabilitar uma porta de acesso assim que a mesma receba uma BPDU;
4.23.3.19. Implementar 4000 VLANs por porta, ativas simultaneamente, através do protocolo 802.1Q;
4.23.3.20. Permitir a criação, remoção, gerenciamento e distribuição de VLANs de forma dinâmica através de portas configuradas como tronco IEEE 802.1Q utilizando o protocolo MVRP segundo o padrão IEEE802.1ak;
4.23.3.21. Possibilitar a coleta de estatisticas de tráfego baseada em VLANs IEEE 802.1Q e double-tagged VLANs IEEE 802.1ad;
4.23.3.22. Implementar MAC Based VLAN;
4.23.3.23. Implementar VLAN Translation;
4.23.3.24. Implementar VLAN Aggregation ou funcionalidade que permita o compartilhamento de uma mesma subnet e de um mesmo endereço IPv4 utilizado como default-gateway por hosts de diferentes VLANs;
4.23.3.25. Implementar Private VLANs;
4.23.3.26. Implementar Port Isolation ou funcionalidade que permita isolamento de portas específicas do switch. As portas isoladas não devem se comunicar entre si, porém podem se comunicar com qualquer outra porta no equipamento que não esteja isolada;
4.23.3.27. Implementar IEEE 802.1ad com a possibilidade de associar CVIDs específicos para diferentes SVIDs (selective Q-in-Q ou 802.1ad CEP). A implementação deverá permitir a tradução do CVID;
4.23.3.28. Implementar IEEE 802.1ag (Connectivity Fault Management);
4.23.3.29. Implementar funcionalidade baseada na recomendação do ITU-T Y.1731 com medição de, no mínimo, Frame Delay;
4.23.3.30. Implementar o protocolo ITU-T G.8032 ERPS;
4.23.3.31. Implementar protocolo de resiliência em camada 2, específico para topologias em anel, que permita tempo de convergência inferior a 200 ms;
4.23.3.32. Implementar IEEE 802.1ab Link Layer Discovery Protocol (LLDP);
4.23.3.33. Implementar LLDP-MED (Media Endpoint Discovery);
4.23.3.34. Implementar a configuração de telefones IP de forma automática, permitindo a detecção do aparelho através do protocolo LLDP e a configuração de VLAN e QoS para a porta;
4.23.3.35. Implementar a configuração de telefones IP de forma automática, permitindo a detecção do aparelho através do protocolo LLDP e repasse de configuração de VLAN e QoS para o telefone através do protocolo LLDP-MED.
4.23.4. FUNÇÕES DE CAMADA 3
4.23.4.1. Suportar o armazenamento de, no mínimo, 400 (quatrocentos) rotas em IPv4 em hardware;
4.23.4.2. Suportar o armazenamento de, no mínimo, 200 (duzentos) rotas em IPv6 em hardware;
4.23.4.3. Suportar agregação de links conforme padrão IEEE 802.3ad com, no mínimo, 128 grupos, sendo 8 links agregados por grupo;
4.23.4.4. Implementar, no mínimo, 500 interfaces IP (IPv4 ou IPv6);
4.23.4.5. Implementar os protocolos de roteamento IP: RFC 1058 – RIP v1 e RFC 2453 – RIP v2;
4.23.4.6. Implementar o protocolo de roteamento OSPFv2, incluindo autenticação MD5;
4.23.4.7. Implantar OSPF de acordo com as seguintes RFCs:
1.25.4.7.1 RFC 1587 The OSPF NSSA Option;
1.25.4.7.2 RFC 1765 OSPF Database Overflow;
1.25.4.7.3 RFC 2370 The OSPF Opaque LSA Option;
1.25.4.7.4 RFC 3623 Graceful OSPF Restart".
4.23.4.8. Implementar PIM Snooping;
4.23.4.9. Implementar protocolo de multicast PIM-SM para IPv4 e IPv6;
4.23.4.10. Implementar VRRPv3 (RFC 5798);
4.23.4.11. Implementar Dual Stack, ou seja, IPv6 e IPv4, com suporte as seguintes funcionalidades/RFCs:
1.25.4.11.1 RFC 1981, Path MTU Discovery for IPv6, August 1996 - Host Requirements; 1.25.4.11.2 RFC 5095, Internet Protocol, Version 6 (IPv6) Specification;
1.25.4.11.3 RFC 4861, Neighbor Discovery for IP Version 6, (IPv6);
1.25.4.11.4 RFC 2462, IPv6 Stateless Address Auto configuration - Host Requirements; 1.25.4.11.5 RFC 2463, Internet Control Message Protocol (ICMPv6) for the IPv6 Specification; 1.25.4.11.6 RFC 2464, Transmission of IPv6 Packets over Ethernet Networks;
1.25.4.11.7 RFC 2465, IPv6 MIB, General Group and Textual Conventions; 1.25.4.11.8 RFC 2466, MIB for ICMPv6;
1.25.4.11.9 RFC 3513, Internet Protocol Version 6 (IPv6) Addressing Architecture; 1.25.4.11.10 RFC 3587, Global Unicast Address Format".
4.23.4.12. Implementar os seguintes protocolos em IPv6: Ping, Traceroute, Telnet, SSHv2, SNMP, Syslog, SNTP e DNS.
4.23.4.13. Implementar IPv6 de acordo com as seguintes RFCs:
1.25.4.13.1 RFC 1981, Path MTU Discovery for IPv6, August 1996 - Router Requirements; 1.25.4.13.2 RFC 2462, IPv6 Stateless Address Auto configuration - Router Requirements; 1.25.4.13.3 RFC 2080, RIPng;
1.25.4.13.4 RFC 2462, IPv6 Stateless Address Auto configuration - Router Requirements; 1.25.4.13.5 RFC 2710, IPv6 Multicast Listener Discovery v1 (MLDv1) Protocol; 1.25.4.13.6 RFC 3810, IPv6 Multicast Listener Discovery v2 (MLDv2) Protocol; 1.25.4.13.7 RFC 6106, IPv6 Router Advertisement Options for DNS Configuration;
4.23.4.14. Implementar BFD (Bidirectional Forwarding Detection);
4.23.4.15. Implementar Policy Based Routing.
4.23.5. QUALIDADE DE SERVIÇO
4.23.5.1. Implementar Rate limiting de entrada em todas as portas. A granularidade deve ser configurável em intervalos de 64Kbps para portas de até 1Gbps. Caso o equipamento ofertado possua suporte a portas 10Gbps, a granularidade para este tipo de interface deve ser configurável em intervalos de 1Mbps. A implementação de Rate Limiting deve permitir a classificação do tráfego utilizando-se ACLs e parâmetros, MAC origem e destino (simultaneamente) IP origem e destino (simultaneamente), portas TCP, portas UDP e campo 802.1p.;
4.23.5.2. Implementar Rate Shaping de saída em todas as portas. A granularidade deve ser configurável em intervalos de 64Kbps para portas de até 1Gbps. Caso o equipamento ofertado possua suporte a portas 10Gbps, a granularidade para este tipo de interface deve ser configurável em intervalos de 1Mbps;
4.23.5.3. A funcionalidade de Rate Shaping deve permitir a configuração de CIR (Commited Rate), banda máxima, banda mínima e peak rate;
4.23.5.4. Implementar a leitura, classificação e remarcação de QoS (802.1p e DSCP);
4.23.5.5. Implementar remarcação de prioridade de pacotes Layer 3, remarcando o campo DiffServ para grupos de tráfego classificados segundo portas TCP e UDP, endereço/subrede IP, VLAN e MAC origem e destino;
4.23.5.6. Implementar 8 filas de prioridade em hardware por porta;
4.23.5.7. Implementar os algoritmos de gerenciamento de filas WRR (Weighted Round Robin), WDRR (Weighted Deficit Round Robin) e SP (Strict Priority);
4.23.5.8. Implementar, ao menos dois dos algoritimos acima, simultaneamente em uma mesma porta;
4.23.5.9. Implementar as seguintes RFCs:
1.25.5.9.1 RFC 2474 DiffServ Precedence;
1.25.5.9.2 RFC 2598 DiffServ Expedited Forwarding (EF);
1.25.5.9.3 RFC 2597 DiffServ Assured Forwarding (AF);
1.25.5.9.4 RFC 2475 DiffServ Core and Edge Router Functions.
4.23.5.10. Implementar classificação de tráfego para QoS em Layer1-4 (Policy-Based Mapping) baseado em MAC origem e destino, IP origem e destino, TCP/UDP port, Diffserv e 802.1p;
4.23.5.11. Implementar detecção de oscilação (flap) de links, permitindo desabilitar uma porta caso a porta oscile acima de um limiar configurado.
4.23.6. GERENCIAMENTO E SEGURANÇA
4.23.6.1. Implementar, no mínimo, 2.000 (duas mil) regras de ACL de entrada (ingress ACLs);
4.23.6.2. Implementar, no mínimo, 500 (quinhentas) regras de ACL de saída (egress ACLs);
4.23.6.3. Implementar upload e download de configuração em formato ASCII ou XML, permitindo a edição do arquivo de configuração e, posteriormente, o download do arquivo editado para o equipamento;
4.23.6.4. Implementar TACACS+ segundo a RFC 1492;
4.23.6.5. Implementar autenticação RADIUS com suporte a:
1.25.6.5.1 RFC 2865 RADIUS Authentication;
1.25.6.5.2 RFC 2866 RADIUS Accounting;
1.25.6.5.3 RFC 3579 RADIUS EAP support for 802.1X".
4.23.6.6. A implementação de RADIUS deve suportar alteração dinâmica de parâmetros de autorização de uma sessão que já esteja ativa;
4.23.6.7. A implementação de RADIUS e TACACS+ deve estar disponível para autenticação de usuários via Telnet e Console serial;
4.23.6.8. Implementar per-command authorization para RADIUS e TACACS+;
4.23.6.9. Possuir DNS Client para IPv4 segundo a RFC 1591 e DNS Client para IPv6;
4.23.6.10. Possuir Telnet client and server segundo a RFC 854;
4.23.6.11. Implementar os seguintes grupos de RMON através da RFC 1757: History, Statistics, Alarms e Events;
4.23.6.12. Implementar RMON2-probe configuration segundo a RFC 2021, podendo ser implementada internamente no switch ou externamente, por meio de probe em hardware utilizando uma porta 1000BaseTX;
4.23.6.13. Implementar sFlow ou NeVlow, em hardware;
4.23.6.14. Implementar a atualização de imagens de soGware e configuração através de um servidor TFTP;
4.23.6.15. Suportar múltiplos servidores Syslog;
4.23.6.16. Implementar ajuste de clock do equipamento utilizando NTP com autenticação MD5 e SNTP;
4.23.6.17. Implementar Port Mirroring, permitindo espelhar até 128 portas fisicas ou 16 VLANs para até 16 portas de destino (portas de análise). Deve ser possível
configurar mais de uma sessão de espelhamento simultânea;
4.23.6.18. Implementar RSPAN (Remote Mirroring), permitindo espelhar o tráfego de uma porta ou VLAN de um switch remoto para uma porta de um switch local (porta de análise);
4.23.6.19. Implementar gerenciamento através de SNMPv1 (RFC 1157), v2c (RFCs 1901 a 1908), v3 (RFCs 3410 a 3415) e SNMP para IPv6;
4.23.6.20. Implementar SMON de acordo com a RFC 2613;
4.23.6.21. Implementar cliente e servidor SSHv2;
4.23.6.22. Implementar cliente e servidor SCP e servidor SFTP;
4.23.6.23. Implementar gerenciamento via web com suporte a HTTP e HTTPS/SSL, permitindo visualização gráfica da utilização (em percentual, bytes e pacotes) das portas;
4.23.6.24. A interface gráfica deve permitir visualização de informações do sistema (VLAN, Portas, Fonte e Fans), monitoramento de Log, utilização de portas, QoS e configuração de portas, VLANs e ACLs;
4.23.6.25. O equipamento ofertado deve possuir um sistema operacional modular;
4.23.6.26. O sistema operacional deve possuir função grep/pipe para filtrar a saída de determinado comando;
4.23.6.27. O sistema operacional deve possuir comandos para visualização e monitoração de cada processo, sendo possível verificar por processo qual o consumo de cpu, process-id e qual o consumo de memória por processo;
4.23.6.28. O sistema operacional deve possuir comandos para que processos sejam terminados ou reiniciados sem que seja necessário a reinicialização do equipamento. Esta funcionalidade deve estar disponível pelo menos para Telnet, TFTP, HTTP e LLDP na versão atual;
4.23.6.29. Implementar linguagem de scripting baseada em Python, permitindo a automatização de tarefas. A linguagem deve implementar estruturas de controle como loops e execução condicional e permitir a definição de variáveis;
4.23.6.30. Implementar protocolo de monitoramento de status de comunicação entre dois switches, que possibilite que uma porta seja desabilitada caso seja detectada uma falha de comunicação entre os dois peers;
4.23.6.31. Implementar funcionalidade que permita sua auto-configuração através dos protocolos DHCP e TFTP, permitindo o provisionamento em massa com o mínimo de intervenção humana;
4.23.6.32. Deve disponibilizar API (Aplication Programming Interface) aberta para integração com aplicações;
4.23.6.33. Implementar funcionalidade que permita que somente endereços designados por um servidor DHCP tenham acesso à rede;
4.23.6.34. mplementar funcionalidade que permita que somente servidores DHCP autorizados atribuam configuração IP aos clientes DHCP (Trusted DHCP Server);
4.23.6.35. Implementar Gratuitous ARP Protection;
4.23.6.36. mplementar detecção e proteção contra-ataques Denial of Service (DoS) direcionados a CPU do equipamento por meio da criação dinâmica e automática de regras para o bloqueio do tráfego suspeito;
4.23.6.37. Implementar limitação de número de endereços MAC aprendidos por uma porta, para uma determinada VLAN;
4.23.6.38. Implementar travamento de endereços MAC, permitindo a adição estática de endereços para uma determinada porta ou utilizando os endereços existentes na tabela MAC. O acesso de qualquer outro endereço que não esteja previamente autorizado deve ser negado;
4.23.6.39. Implementar login de rede baseado no protocolo IEEE 802.1x, permitindo que a porta do switch seja associada a VLAN definida para o usuário no servidor RADIUS;
4.23.6.40. A implementação do IEEE 802.1x deve incluir suporte a Guest VLAN, encaminhando o usuário para esta VLAN caso este não possua suplicante 802.1x ativo, em caso de falha de autenticação e no caso de indisponibilidade do servidor AAA;
4.23.6.41. Implementar múltiplos suplicantes por porta, onde cada dispositivo deve ser autenticado de forma independente, podendo ser encaminhados a VLANs distintas. As múltiplas autenticações devem ser realizadas através de IEEE 802.1x;
4.23.6.42. Implementar autenticação baseada em web, com suporte a SSL, através de RADIUS ou através da base local do switch;
4.23.6.43. Implementar autenticação baseada em endereço MAC, através de RADIUS ou através da base local do switch;
4.23.6.44. Implementar ACLs de entrada (ingress ACLs) em hardware, baseadas em critérios da camada 2 (MAC origem e destino e campo 802.1p), camada 3 (IP origem e destino) e camada 4 (portas TCP e UDP), em todas as interfaces e VLANs, com suporte a endereços IPv6;
4.23.6.45. As ACLs devem ser configuradas para permitir, negar, aplicar QoS, espelhar o tráfego para uma porta de análise, criar entrada de log e incrementar contador;
4.23.6.46. Implementar funcionalidade que permita a execução de ACLs em um determinado horário do dia (time-based ACLs);
4.23.6.47. Implementar políticas por usuário, permitindo que as configurações de ACL, QoS sejam aplicadas na porta utilizada para a conexão à rede, após a autenticação;
4.23.6.48. Implementar Policy Based Switching, ou seja, possibilitar que o tráfego classificado por uma ACL seja redirecionado para uma porta fisica específica;
4.23.6.49. Implementar funcionalidade que permita o mapeamento de usuários identificados via Kerberos (com a credencial de usuário no domínio), IEEE 802.1x e LLDP, provendo informações como endereço MAC, VLAN e porta fisica. Estas informações devem estar disponíveis na linha de comando (CLI) do equipamento;
4.23.6.50. Suportar protocolo OpenFlow versão 1.0 ou superior.
4.23.7. REPASSE DE CONHECIMENTO E INSTALAÇÃO ASSISTIDA
4.23.7.1. Repasse de conhecimento avançado abrangendo configuração, segurança, disponibilidade e melhores práticas na operação dos equipamentos e soGwares adquiridos;
4.23.7.2. O repasse de conhecimento deverá ser realizado nas seguintes condições:
1.25.7.2.1 Nas dependências do Palácio Rio Madeira, em data e horários previamente acordados entre as partes;
1.25.7.2.2 Ministrado no período mínimo de 8 horas, incluindo teoria e laboratórios;
1.25.7.2.3 O repasse deverá ser feito para até 08 participantes.
4.23.7.3. Considerar, para efeitos de treinamento, no mínimo, os seguintes componentes da solução:
1.25.7.3.1 Administração e configurações básicas do concentrador de rack;
1.25.7.3.2 Visualização das configurações;
1.25.7.3.3 Verificação do empilhamento ou cluster;
1.25.7.3.4 Verificação de logs;
1.25.7.3.5 Configuração de SNMP, DNS e NTP;
1.25.7.3.6 Configuração de LDP ou CDP;
1.25.7.3.7 Criação de VLANs;
1.25.7.3.8 Criação de Interfaces VLANs;
1.25.7.3.9 Criação de agregação de portas; 1.25.7.3.10 Marcação de portas.
4.23.7.4. A ementa do curso deverá ser proposta pela CONTRATADA e enviada com antecedência ao início do repasse;
4.23.7.5. Os materiais de apoio poderão ser em português ou inglês, sendo impressões ou digitais;
4.23.7.6. A ementa citada no subitem anterior deverá ser aceita pela CONTRATANTE, podendo ela também sugerir inclusão ou exclusão de algum tópico;
4.23.7.7. Havendo necessidade deverão ser utilizados equipamentos similares aos adquiridos. Sendo possível poderão ser utilizados os próprios equipamentos adquiridos;
4.23.7.8. Ser realizado por profissional que tenha qualificação técnica necessária quanto à instalação, configuração e gerenciamento da solução adquirida;
4.23.7.9. Instalar dentro das boas práticas de cada fabricante.
4.24. MÓDULO TIPO 1 – GBIC SFP 1G
4.24.1. REQUISITOS GERAIS
4.24.1.1. Ser padrão SFP;
4.24.1.2. Atender o padrão 1 Gigabit Ethernet, até 100m;
4.24.1.3. Deve possuir conector do tipo RJ45;
4.24.1.4. Deve atender ao padrão 1000BASE-X;
4.24.1.5. Deve ser do mesmo fabricante dos switches ofertados.
4.25. MÓDULO TIPO 2 – GBIC SFP+ 10G SR
4.25.1. REQUISITOS GERAIS
4.25.1.1. Ser padrão SFP+;
4.25.1.2. Atender o padrão 10 Gigabit Ethernet IEEE802.3ae, 850nm, MMF, até 300m;
4.25.1.3. Possuir conector do tipo LC;
4.25.1.4. Atender ao padrão 10GBASE-SR ou similar;
4.25.1.5. Ser do mesmo fabricante dos switches ofertados;
5. DO PRAZO E LOCAL DE ENTREGA:
5.1. Do prazo: O prazo de entrega dos itens, objeto desta Ata, será de até 60 (sessenta) dias, contados da data do recebimento da Nota de Empenho
ou assinatura do contrato, o que ocorrer primeiro. Este prazo poderá ser dilatado em casos excepcionais, mediante apresentação de jusficava, com concordância da Administração.
5.2. Do Local de entrega:
5.3. Os equipamentos deverão ser entregues instalados no Datacenter localizado na nova Sede da Secretaria de Estado da Educação – SEDUC, Xx. Xxxxxxxxxx, xx 0000 - Xx. Xxxxx Xxxx Xxxx, XXX 00.000-000 - Xxxxxxx, Xxxxx, das 08:00 às 12:00 das 14:00 às 18:00 horas;
5.4. O acesso ao Datacenter e ao Container deverá ser acordado com a Superintendência de Tecnologia - SITI, que designará técnicos para acompanhar o pessoal da CONTRATADA;
5.5. A Contratada deverá entrar em contato prévio para ajustar os detalhes da entrega; e
5.6. Maiores informações podem ser obtidas pelos telefones (00) 0000-0000 Gerência de Suporte de Redes.
6. DO RECEBIMENTO, DA FORMA DE ENTREGA:
6.1. Executado o Contrato, o seu objeto será recebido pela Gerência de Suporte de Redes, conforme art. 73, inciso II, letras ‘a’ e ‘b’, e ainda, § 2º da Lei Federal nº. 8.666/93;
6.2. O recebimento provisório ou definitivo não exclui a responsabilidade civil pela solidez e segurança do material, nem éco-profissional pela perfeita execução do contrato, dentro dos limites estabelecidos pela lei ou pelo Instrumento Contratual;
6.3. Os materiais/bens serão recebidos por uma Comissão de Recebimento de Materiais, que terá, juntamente com o Requisitante, a incumbência de, dentre outras atribuições, aferir a quantidade, qualidade e adequação dos materiais entregues;
6.4. Caso sejam insatisfatórios os materiais, lavrar-se-á Termo de Recusa, no qual se consignarão as desconformidades com as especificações. Nesta
hipótese, todo o serviço em questão será rejeitado, devendo ser refeito em tempo hábil para que não prejudique o andamento das atividades da CONTRATANTE, quando se realizarão novamente as verificações constantes nos itens referenciados, ficando suspenso o pagamento da nota fiscal/fatura, até a execução das correções necessárias, sem prejuízo da aplicação das sanções previstas neste termo, em virtude do decorrente atraso de entrega que será verificado para a hipótese;
6.5. Aceitos os materiais/bens, será atestada a Nota Fiscal, autorizando o pagamento;
6.6. Não aceito o(s) bem(s) entregue(s), será comunicado à empresa adjudicatária, para que proceda a respectiva e imediata substituição, prazo no prazo máximo de 05 (cinco) dias, para que se possa adequar o efetivamente entregue com aquele que efetivamente se pretende adquirir;
6.7. Expedida a Nota de Xxxxxxx, o recebimento de seu objeto ficará condicionado a observância das normas condas no art. 40, inciso XVI, c/c o art. 73 inciso II, “a” e “b”, da Lei 8.666/93 e alterações.
7. DAS CONDIÇÕES DE RECEBIMENTO DOS MATERIAIS:
7.1. As soluções hiperconvergentes com armazenamento a serem entregues pela contratada deverão obedecer rigorosamente às especificações do
Termo de Referência, sob pena de não serem aceitas pelo agente responsável pelo recebimento, sem prejuízo das sanções administravas e legais previstas no Termo;
7.2. Não serão aceitos, no momento da entrega, produtos de marca diferente daquelas constantes na proposta vencedora. Quanto a problemas de
qualidade dos Softwares, a licitante notificada pela Administração Pública, será responsável pela troca do produto que apresentar problemas, mesmo que já tenha sido distribuído; e
7.3. Além da entrega da mercadoria em suas embalagens originais, no local designado pela Administração, deverá a licitante vencedora, fazer a
instalação, configuração inicial, integração, dar treinamento e suporte técnico do produtos no local indicado pelo servidor, comprometendo-se, ainda, integralmente, com eventuais danos causados a estes.
8. DOS RECURSOS ORÇAMENTÁRIOS:
8.1. Os recursos orçamentários correrão:
8.2. Dotação Orçamentária: 2020.2401.12.122.4200.4218.03.100.90, Natureza de Despesa: 4.4.90.52.11, Fonte de Recurso: 100.
9. DO PAGAMENTO:
9.1. O faturamento será constituído de valor apurado pelo fornecedor, com base única e exclusivamente no quantitativo dos materiais/serviços entregues e atestados, conforme Notas de Empenho emitidas, incluindo todos os custos diretos e indiretos pertinentes, mediante a apresentação de ÚNICA
Nota Fiscal Eletrônica pela contratada em 02 (duas) vias (ou outra, com descrição detalhada de todos os itens faturados, desde que atenda a legislação tributária vigente), devendo conter no corpo da nota fiscal, a descrição do objeto, o número do contrato ou Nota de Empenho, e os dados bancários da CONTRATADA (n° banco, n° agência e n° da conta corrente, somente no caso destes não corresponderem ao informado na licitação e contrato) para aceite, até o dia 05 (cinco) do mês subsequente ao Termo de Recebimento;
9.2. A Administração procederá o recebimento e conferência dos produtos, conforme competências definidas neste Termo de Referência, consoante
aos valores e itens mencionados no documento fiscal apresentado pela Contratada, no prazo definido neste instrumento, procedendo ao ateste de conformidade pela Administração, conforme disposto no art. 73 da Lei nº8.666/93;
9.3. O processamento do pagamento realizar-se-á conforme abaixo:
9.4. O equipamento será recebido e conferido pela comissão de recebimento em até 15 (quinze) dias úteis - conforme itens 6.1;
9.5. A liquidação e processamento da despesa correspondente ao valor efetivamente apurado e conferido pelos fiscais e comissão de recebimento
do contrato, deduzindo as glosas e sanções aplicadas que porventura tenham sido verificadas, será efetuada por esta pasta no prazo máximo de 05 (cinco) dias a contar do recebimento da documentação, quando encaminhará os documentos para análise da Controladoria Geral do Estado ou Controle Interno, conforme o caso;
9.6. O órgão de controle deve efetuar a análise e emitir parecer no prazo de 05 (cinco) dias a contar do recebimento dos autos, devolvendo-os para fins de inclusão na ordem cronológica de pagamento caso não haja apontamentos;
9.7. Havendo apontamentos, será incluído para pagamento, no prazo máximo de 05 (cinco) dias a contar do retorno dos autos, devidamente regularizados;
O pagamento da Nota Fiscal correspondente ao valor definitivo processado pela Administração se dará através da Secretaria de Estado da Educação - SEDUC ou setor equivalente competente, mediante emissão de Ordem Bancária, obedecendo a xxxxx xxxxxxxxxxx xxxxxxxxxxxx, xx xxxxx xx 00 (xxxxxx) dias contados a partir da data final do período de adimplemento de cada parcela (verificação de conformidade da documentação), consoante ao definido nos art. 40, inciso XIV, alínea “a” da Lei Federal nº 8.666/93;
9.8. Ocorrendo erro no documento da cobrança, este será devolvido e o pagamento será sustado para que a CONTRATADA tome as medidas necessárias, passando o prazo para o pagamento a ser contado a partir de data da reapresentação do mesmo;
9.9. Caso se constate erro ou irregularidade de parcela pequena na Nota Fiscal, a ADMINISTRAÇÃO, a seu critério, poderá devolvê-la, para as devidas correções, ou aceitá-las, com a glosa da parte que considerar indevida;
9.10. Na hipótese de devolução, a Nota Fiscal será considerada como não apresentada, para fins de atendimento das condições contratuais;
9.11. Nenhum pagamento controverso será efetuado, enquanto pendente de liquidação, qualquer obrigação financeira que lhe foi imposta, em virtude de penalidade ou inadimplência, sem que isso gere direito ao pleito do reajuste de preços ou correção monetária;
9.12. Na hipótese das notas fiscais apresentados conterem erros ou dúvidas quanto à exatidão ou documentação, a CONTRATANTE poderá pagar
apenas a parcela não controvertida no prazo fixado para pagamento, ressalvado o direito da CONTRATADA de reapresentar, para cobrança as partes controvertidas com as devidas justificavas. Neste caso restabelecem-se os prazos acima elencados contado a partir do recebimento, para efetuar uma análise e o pagamento, conforme a fase processual correspondente;
9.13. A administração não pagará, sem que tenha autorização prévia e formal, nenhum compromisso que lhe venha a ser cobrado diretamente por terceiros, seja ou não instituições financeiras, à exceção de determinações judiciais, devidamente protocoladas no órgão;
9.14. Os eventuais encargos financeiros, processuais e outros, decorrentes da inobservância, pela licitante, de prazo de pagamento, serão de sua exclusiva responsabilidade;
9.15. A ADMINISTRAÇÃO efetuará retenção, na fonte, dos tributos e contribuições sobre todos os pagamentos à CONTRATADA, conforme o caso e exigências legais aplicáveis;
9.16. Quando da ocorrência de eventuais atrasos de pagamento provocados exclusivamente pela Administração, o valor devido deverá ser acrescido
de atualização financeira, e sua apuração se fará desde a data de seu vencimento até a data do efetivo pagamento, em que os juros de mora serão calculados à taxa de 0,5% (meio por cento) ao mês, ou 6% (seis por cento) ao ano, mediante aplicação das seguintes fórmulas:
I=(TX/100) 365
EM = I x N x VP
Onde:
I = Índice de atualização financeira;
TX = Percentual da taxa de juros de mora anual; EM = Encargos moratórios;
N = Número de dias entre a data prevista para o pagamento e a do efetivo pagamento; VP = Valor da parcela em atraso
9.17. Na hipótese de pagamento de juros de mora e demais encargos por atraso, os autos deverão ser instruídos com as justificavas e motivos, e ser
submetidos à apreciação da autoridade superior competente, que adotará as providências para verificar se é ou não caso de apuração de responsabilidade, identificação dos envolvidos e imputação de ônus a quem deu causa;
9.18. A Contratada não poderá se valer do contrato para assumir obrigações perante terceiros, dando-o como garantia, nem utilizar os direitos de crédito a serem auferidos em função dos materiais, em quaisquer operações de desconto bancário, sem prévia autorização do Ordenador de Despesas;
9.19. O prazo para pagamento da Nota Fiscal só será contado da data de sua validação, considerando o trâmite administrativo;
9.20. A Contratante não se responsabilizará por qualquer despesa que venha a ser efetuada pela contratada, que porventura não tenha sido acordada no contrato;
9.21. Diante da conferência, a Nota Fiscal deverá ser atestada pela Comissão designada, conforme disposto nos argos 67 e 77 da Lei 8.666/93;
9.22. Considerar-se-á como sendo a data do pagamento a data da emissão da respectiva ordem bancária;
9.23. Em hipótese alguma será concedido reajustamento dos preços propostos e o valor constante da Nota Fiscal, quando da sua apresentação, não sofrerá qualquer atualização monetária até o efetivo pagamento; e
9.24. É condição para o pagamento do valor constante de cada Nota Fiscal, a comprovação de recolhimento de encargos sociais cabíveis, bem como a
apresentação de Prova de Regularidade com o Fundo de Garantia por Tempo de Serviço (FGTS) e Cerdão Negava da Receita Estadual, Municipal e Federal, além da Cerdão Negava de Débitos Trabalhistas – CNDT e das demais exigências legais em vigência, sendo aceitas as Cerdões Positivas com efeito de negavas, podendo ser verificadas nos sítios eletrônicos, e demais obrigações legais.
10. DA FISCALIZAÇÃO E DA SUBCONTRATAÇÃO:
10.1. Durante o período de vigência do Contrato, a entrega do objeto será acompanhada e fiscalizada por comissão, devidamente designada para
esse fim, que determinará o que for necessário para regularização de faltas ou defeitos, permitida a assistência de terceiros, nos termos do art. 67 da Lei Federal nº 8.666/93;
10.2. Caso o produto entregue não esteja em conformidade com as especificações do Edital, a fiscalização relatará as falhas ou irregularidades
encontradas, ficando a empresa contratada, com o recebimento do relatório, ciente das irregularidades apontadas e de que estará, conforme o caso, passível de sanções;
10.3. Caberá a empresa contratada sanar as falhas apontadas, submetendo posteriormente o objeto rejeitado à nova verificação da fiscalização;
10.4. A fiscalização de que trata o subitem acima não exclui nem reduz a responsabilidade da empresa vencedora pelos danos causados diretamente ou a terceiros, decorrentes de sua culpa ou dolo na execução do futuro contrato em conformidade com o art. 70 da Lei nº 8.666, de 1993; e
10.5. Não será permitido a subcontratação, cessão e/ou transferência total ou parcial do objeto deste Termo de Referência.
11. DAS OBRIGAÇÕES DA FUTURA DETENTORA DO REGISTRO:
11.1. Além das demais obrigações exigidas em Lei, a empresa detentora do Registro deverá:
11.1.1 Entregar os materiais de acordo com as especificações contidas neste termo de referência;
11.1.2 Manter durante a execução do contrato, todas as condições de habilitação e qualificação exigidas na licitação;
11.1.3 Entregar o material licitado no preço, forma e prazo estipulados na proposta;
11.1.4 A LICITANTE deverá apresentar declaração emitida pela mesma de que possui ou possuirá, durante a execução contratual, profissionais qualificados detentores de certificados técnicos na solução proposta responsáveis pela execução dos serviços de suporte técnico;
11.1.5 Todos os serviços de instalação, configuração e transferência de conhecimento técnico deverão ser executados de forma presencial, por especialista(s) técnico(s) certificado(s) nos componentes pelo fabricante dos mesmos com a devida apresentação de certificado(s) técnico(s) emitido(s) pelo fabricante do(s) produto(s):
11.1.5.1 Profissional(is) detentor(es) de certificação técnica que comprove a habilidade de instalação, configuração e gerenciamento da solução integradas, mediante a apresentação da certificação e – se em regime CLT: cópia da carteira de trabalho – se em regime terceirizado ou autônomo: contrato de prestação de serviços; e
11.1.5.2 Profissional(is) detentor(es) da certificação PMP (Project Management Professional) fornecida pelo PMI (Project Management Institute), ou correspondente, comprovando mediante a apresentação da certificação e – se em regime CLT: cópia da carteira de trabalho – se e regime terceirizado ou autônomo: contrato de prestação de serviços.
11.1.6 Entregar os materiais nas quantidades indicadas pelo órgão requisitante em cada ordem de serviço;
11.1.7 Responsabilizar-se por todos os ônus, encargos, perdas e danos em quando for constatado que tenham sido ocasionados em decorrência do fornecimento do objeto;
11.1.8 Responsabilizar-se pelas providências e obrigações estabelecidas em legislação específica de acidentes trabalho quando em ocorrência de espécie forem vítimas os seus empregados, no desempenho de suas atribuições ou em contato com eles, ainda que a ocorrência tenha sido nas dependências da CONTRATANTE;
11.1.9 Arcar com todas as despesas, diretas ou indiretas, decorrentes do cumprimento das obrigações assumidas e todos os tributos incidentes, sem qualquer ônus à CONTRATANTE, devendo efetuar os respectivos pagamentos na forma e nos prazos previstos em Lei;
11.1.10 Reparar, corrigir, remover ou substituir, às suas expensas, no total ou em parte, o produto adquirido, no prazo máximo de 10 (dez) dias, a contar da notificação da contratada. Cabe ressaltar que a legislação prevê 30 (trinta) dias, porém, por serem equipamentos essenciais para toda a estrutura de tecnologia do Estado, se faz necessária essa redução
no período, em consonância com o previsto no item 20 (vinte) do presente Termo;
11.1.11 Entregar o objeto nos locais definidos neste instrumento;
11.1.12 Executar fielmente este contrato, em conformidade com as cláusulas avençadas e normas estabelecidas na Lei nº 8.666/93 e suas alterações, de forma a não interferir no andamento da CONTRATANTE;
11.1.13 Atender prontamente a quaisquer exigências da fiscalização inerentes ao objeto do contrato, sem que disso decorra qualquer ônus para a CONTRATANTE, não implicando a atividade da fiscalização em qualquer exclusão ou redução da responsabilidade da CONTRATADA, inclusive perante terceiros, por qualquer irregularidade; e
11.1.14 Não utilizar as dependências da CONTRATANTE para qualquer atividade estranha ao objeto deste contrato;
11.1.15 Comprovar todas as exigências técnicas por meio de folders, datasheets, catálogos do fabricante e manuais diversos, desde que os mesmos estejam disponíveis no site oficial do fabricante.
Observação: Toda a documentação exigida assegura maior isonomia na avaliação técnica das propostas das empresas licitantes, além de oferecer objetivamente o entendimento correto do escopo de fornecimento dos equipamentos ofertados. Cabe também informar que a falta de transparência na apresentação de todas as documentações técnicas poderá acarretar na
desclassificação da empresa no certame licitatório.
12. DOS DEVERES DO ÓRGÃO CONTRATANTE:
12.1. Promover o acompanhamento e a fiscalização da entrega dos bens adquiridos, por intermédio do fiscal designado, anotando em registro próprio as falhas detectadas e comunicando as ocorrências de fatos que, a seu critério, exijam a adoção de medidas por parte do CONTRATADO;
12.2. Efetuar o pagamento na forma convencionada neste Termo de Referência;
12.3. Prestar os esclarecimentos que venham a ser solicitados pelo CONTRATADO;
12.4. Proporcionar todas as facilidades para que o CONTRATADO possa cumprir suas obrigações dentro das normas e condições estabelecidas;
12.5. Realizar rigorosa conferência das características do objeto deste Termo de Referência, pela Comissão de Recebimento designada, somente atestando os documentos da despesa quando comprovada a entrega total, fiel e correta do produto, ou de parte da entrega a que se referirem;
12.6. Rejeitar, no todo ou em parte, o objeto em desacordo com as obrigações assumidas pelo CONTRATADO; e
12.7. Assegurar que as obrigações descritas neste instrumento somente sejam realizadas pelo CONTRATADO, sendo vedada a interveniência de terceiros estranhos ao contrato, salvo se autorizado prévia e expressamente.
13. DAS SANÇÕES:
13.1. Além daquelas determinadas por leis, decretos, regulamentos e demais dispositivos legais, a CONTRATADA estará sujeita a:
13.1.1 Sem prejuízo das sanções cominadas no art. 87, I, III e IV, da Lei nº 8.666/93, pela inexecução total ou parcial do contrato, a Administração poderá, garantida a prévia e ampla defesa, aplicar à Contratada multa de até 10% (dez por cento) sobre a parcela inadimplida;
13.1.2 Se a adjudicatária recusar-se a retirar o instrumento contratual injustificadamente ou se não apresentar situação regular na ocasião dos recebimentos, garantida a prévia e ampla defesa, aplicar à Contratada multa de até 10% (dez por cento) sobre o valor adjudicado;
13.1.3 A licitante, adjudicatária ou contratada que, convocada dentro do prazo de validade de sua proposta, não celebrar o instrumento contratual, deixar de entregar ou apresentar documentação falsa exigida para o certame, ensejar o retardamento da execução de seu objeto, não mantiver a proposta, falhar ou fraudar na execução do instrumento contratual, comportar-se de modo inidôneo ou cometer fraude fiscal, garantida a prévia e ampla defesa, ficará impedida de licitar e contratar com o Estado, e será descredenciado no Comprasnet, pelo prazo de até 05 (cinco) anos, sem prejuízo das multas previstas no Edital e das demais cominações legais, devendo ser incluída a penalidade no
SICAFI e no CADFOR Cadastro Unificado de Fornecedor do Estado de Goiás;
13.1.4 A multa, eventualmente imposta à Contratada, será automaticamente descontada da fatura a que fizer jus, acrescida de juros moratórios de 1% (um por cento) ao mês. Caso a contratada não tenha nenhum valor a receber do Estado, ser-lhe-á concedido o prazo de 05 (cinco) dia úteis, contados de sua intimação, para efetuar o pagamento da multa. Após esse prazo, não sendo efetuado o pagamento, serão deduzidos da garantia. Mantendo-se o insucesso, seus dados serão encaminhados ao órgão competente para que seja inscrita na dívida ativa, podendo, ainda a Administração proceder à cobrança judicial;
13.1.5 As multas previstas nesta seção não eximem a adjudicatária ou contratada da reparação dos eventuais danos, perdas ou prejuízos que seu ato punível venha causar à Administração;
13.1.6 De acordo com a gravidade do descumprimento, poderá ainda a licitante se sujeitar à Declaração de inidoneidade para licitar ou contratar com a Administração Pública enquanto perdurarem os motivos determinantes da punição ou até que seja promovida a reabilitação perante a própria autoridade que aplicou a penalidade, que será concedida sempre que o contratado ressarcir a Administração pelos prejuízos resultantes e depois de decorrido o prazo da sanção aplicada com base na legislação vigente;
13.1.7 A sanção denominada “Advertência” só terá lugar se emitida por escrito e quando se tratar de faltas leves, assim entendidas como aquelas que não acarretarem prejuízos significativos ao objeto da contratação, cabível somente até a segunda aplicação (reincidência) para a mesma infração, caso não se verifique a adequação da conduta por parte da
Contratada, após o que deverão ser aplicadas sanções de grau mais significativo;
13.1.8 São exemplos de infração administrativa penalizáveis, nos termos da Lei nº 8.666, de 1993, da Lei nº 10.520, de 2002, do Decreto nº 3.555, de 2000, e do Decreto nº 5.450, de 2005:
13.1.8.1. Inexecução total ou parcial do contrato;
13.1.8.2. Apresentação de documentação falsa;
13.1.8.3. Comportamento inidôneo;
13.1.8.4. Fraude fiscal; e
13.1.8.5 Descumprimento de qualquer dos deveres elencados no Edital ou no Contrato.
00.0.0.Xx sanções serão aplicadas sem prejuízo da responsabilidade civil e criminal que possa ser acionada em desfavor da Contratada, conforme infração cometida e prejuízos causados à administração ou a terceiros;
13.1.10 Para efeito de aplicação de multas, às infrações são atribuídos graus, com percentuais de multa conforme a tabela a seguir, que elenca apenas as principais situações previstas, não eximindo de outras equivalentes que surgirem, conforme o caso:
13.1.11 As sanções aqui previstas poderão ser aplicadas concomitantemente, facultada a defesa prévia do interessado, no respectivo processo, no prazo de 05 (cinco) dias úteis;
13.1.12. Após 30 (trinta) dias da falta de execução do objeto, será considerada inexecução total do contrato, o que ensejará a rescisão contratual;
13.1.13. As sanções de natureza pecuniária serão diretamente descontadas de créditos que eventualmente detenha a CONTRATADA ou efetuada a sua cobrança na forma prevista em lei;
13.1.14. As sanções previstas não poderão ser relevadas, salvo ficar comprovada a ocorrência de situações que se enquadrem no conceito jurídico de força maior ou casos fortuitos, devidos e formalmente justificados e comprovados, e sempre a critério da autoridade competente, conforme prejuízo auferido;
13.1.15. A autoridade competente, na aplicação das sanções, levará em consideração a gravidade da conduta do infrator, o caráter educativo da pena, bem como o dano causado à Administração, observado o princípio da proporcionalidade;
13.1.16. A sanção será obrigatoriamente registrada no Sistema de Cadastramento Unificado de Fornecedores – SICAF, bem como em sistemas Estaduais;
13.1.17. Também ficam sujeitas às penalidades de suspensão de licitar e impedimento de contratar com o órgão licitante e de declaração de inidoneidade, previstas no subitem anterior, as empresas ou profissionais que, em razão do contrato decorrente desta licitação:
13.1.17.1. Tenham sofrido condenações definitivas por praticarem, por meio dolosos, fraude fiscal no recolhimento de tributos;
13.1.17.2. Xxxxxx praticado atos ilícitos visando a frustrar os objetivos da licitação; Demonstrem não possuir idoneidade para contratar com a Administração em virtude de atos ilícitos praticados; e
13.1.17.3. Demonstrem não possuir idoneidade para contratar com a Administração em virtude de atos ilícitos praticados.
13.1.18 A recusa injustificada do adjudicatário em assinar o contrato, aceitar ou retirar o instrumento equivalente, (Nota de Empenho) dentro do prazo estabelecido pela Administração, caracteriza o descumprimento total da obrigação assumida, sujeitando-se às penalidades aqui estabelecidas, além das previstas no Termo de Referência;
13.1.19. Na hipótese de apresentar documentação inverossímil ou de cometer fraude, o licitante poderá sofrer sem prejuízo da comunicação do ocorrido ao Ministério Público, quaisquer das sanções previstas, que poderão ser aplicadas cumulativamente; e
13.1.20. Nenhuma sanção será aplicada sem o devido processo administrativo, que prevê defesa prévia do interessado e recurso nos prazos definidos em Lei, sendo-lhe franqueada vista ao processo.
14. DA COMPRA ATRAVÉS DE REGISTRO DE PREÇOS:
14.1. A Lei 8.666/93, especificamente eu seu artigo 15º, aduz:
“Art. 15º As compras, sempre que possível, deverão: (...)
II - ser processadas através de sistema de registro de preços; "
14.2. Já o Decreto 7892/93 regulamenta em seu artigo 3º:
"Art. 3º O Sistema de Registro de Preços poderá ser adotado nas seguintes hipóteses:
(...)
III - quando for conveniente a aquisição de bens ou a contratação de serviços para atendimento a mais de um órgão ou entidade, ou a programas de governo;"
14.3. Xxxxxx Xxxxxx Xxxxx, doutor em Direito do Estado pela PUC-SP em alguns de seus comentários afirma:
“O sistema de Registro de Preços (SRP) é uma das mais úteis e interessantes alternativas de gestão de contratações colocada à disposição da Administração Pública. (...) A sistemática do registro de preços possibilita uma atuação rápida e imediata da Administração Pública, com observância ao princípio da isonomia e garantindo a persecução objetiva da contratação mais vantajosa..."
14.4. Afirma, ainda que o Sistema de Registro de Preços:
“Consiste num procedimento especial a ser adotado, que agiliza as aquisições na área pública, permitindo que os fornecimentos sejam feitos sem grandes entraves burocráticos, adaptados às contingências da vida moderna, eliminando uma série de medidas supérfluas e desnecessárias.”
14.5. Considerando que o Sistema de Registro de Preços oferece maior agilidade na aquisição, e tendo como base o artigo 15, inciso II da Lei 8.666/93, optou-se efetuar a aquisição através do Sistema de Registro de Preços;
14.6. A adoção do Sistema de Registro de Preços enquadra-se, ainda, no Decreto Estadual nº 18.340/2013, artigo 3º, inciso III e V.
14.7. Atendo aos ditames do Decreto retro, e coadunando com a disponibilidade orçamentária, ou seja, com a Ata de Registro de Preços será possível aquisições módicas, sem comprometimento do orçamento dos órgãos, adequando-se as normas do art. 3º inciso II e V.
14.8. Do exposto pode ser observado que o Sistema de Registro de Preços é o meio mais vantajoso, com menor custo e o mais ágil para as aquisições e contratações públicas e deve ser usado sempre que possível.
15. DA GARANTIA E VALIDADE DO OBJETO:
15.1. O produto ofertado deverá atender aos dispositivos da Lei nº 8.078/90 (Código de defesa do Consumidor) e às demais legislações pertinentes;
15.2. O período de garantia técnica deverá ser de, no mínimo, 36 (trinta e seis) meses para os equipamentos especificados neste Termo de Referência
e em seus Anexos, contados a partir da data de recebimento definitivo. Durante este período qualquer falha deverá ser reparada em, no máximo, 10 (dez) dias úteis;
15.3. Todos os componentes dos equipamentos devem ser do próprio fabricante ou estar em conformidade com a política de garantia do mesmo,
não sendo permitida a integração de itens de terceiros que possam acarretar em perda parcial da garantia ou não realização da manutenção técnica pelo próprio fabricante quando solicitada. As exigências de garantia deverão ser comprovadas através de folder ou catálogo da rede credenciada ou na ausência destes por meio de documento oficial do fabricante direcionado a CONTRATANTE para o referido processo.
16. DA JUSTIFICATIVA PARA GARANTIA DE 36 (TRINTA E SEIS) MESES:
16.1. A infraestrutura computacional da Secretaria de Estado da Educação - SEDUC possui altos níveis de complexidade de administração,
especialmente no que se refere ao provisionamento, integração, disponibilidade, flexibilidade, gerenciamento centralizado, segurança das informações, provocando impactos diretos no bom atendimento das crescentes demandas por novos
serviços;
16.2. Como o nome sugere, soluções hiperconvergentes concentram diversos elementos de um datacenter em um só local, e rapidamente assumem um papel de relevância pois permitem gerenciar de forma centralizada uma vasta gama de recursos;
16.3. Assim sendo uma parcela significativa de processamento e armazenamento é transferida para a solução, que se torna uma parte vital da estrutura da qual faz parte;
16.4. Como se pode observar falhas em equipamentos dessa natureza provocam grande impacto nos serviços, cuja interrupção afeta toda a
Administração Pública, podendo, inclusive, causar danos ao erário oriundos de ações na justiça por parte de empresas ou pessoas e como não é possível ter equipamentos em reserva, pois além do valor elevado, eles sofrem atualizações constantes e o processo de licitação é por vezes "moroso" mediante a urgência que o caso requer;
16.5. Vale lembrar que nesse caso específico os equipamentos não são constituídos somente de “material”, possuem também partes “inteligentes” que são os sotiwares desenvolvidos especificamente para eles e que são atualizados muitas vezes durante o período de garantia e suporte;
16.6. Do exposto chega-se a conclusão de que a garantia por 36 (trinta e seis) meses é imprescindível pois todas as empresas com porte para
entregar esse tipo de material já oferecem esses serviços com valores menores na hora da aquisição, sendo mais vantajoso do que a contratação posterior na forma de novos itens, que certamente será necessária
caso seja exigida somente a “garantia legal” de 12 (doze) meses;
16.7. Dessa forma manteremos a solução atualizada e teremos substituições bem mais ágeis caso seja necessário, protegendo a Administração Pública de embaraços administrativos causados por interrupção dos serviços.
17. DO REAJUSTE:
17.1. Os preços serão fixos e irreajustáveis pelo período de 12 (doze) meses.
18. DA FRAUDE E DA CORRUPÇÃO:
As Licitantes deverão observar os mais altos padrões éticos durante o processo licitatório e a execução contratual, estando sujeitas às sanções previstas na legislação brasileira. da ata de registro de preços na imprensa oficial terá efeito de compromisso nas condições ofertadas e pactuadas na proposta apresentada à licitação.
Xxxxx Xxxxxxx Xxxxxx xx Xxxxxxxxxx
Superintendente de Tecnologia
Documento assinado eletronicamente por XXXXX XXXXXXX XXXXXX XX XXXXXXXXXX, Superintendente, em 17/09/2020, às 18:20, conforme art. 2º, § 2º, III, "b", da Lei 17.039/2010 e art. 3ºB, I, do Decreto nº 8.808/2016.
A autenticidade do documento pode ser conferida no site xxxx://xxx.xx.xxx.xx/xxx/xxxxxxxxxxx_xxxxxxx.xxx? acao=documento_conferir&id_orgao_acesso_externo=1 informando o código verificador 000015380714 e o código CRC B27F4CB8.
SUPERINTENDÊNCIA DE TECNOLOGIA
AVENIDA ANHANGUERA 7171 Qd.R1 Lt.26 - Xxxxxx XXXXX XXXXX - XXX 00000-000 - XXXXXXX - XX - .
Referência: Processo nº 202000006035966 SEI 000015380714