Nota Técnica nº 276/2025/GEIT/STD
ASSUNTO
Aquisição de subsistema de armazenamento de dados (Storage) All-Flash, incluindo serviços de instalação, configuração, suporte e garantia por um prazo de 60 (sessenta) meses.
REFERÊNCIAS
Processo nº 00058.051682/2024-39;
Pregão 90021/2025;
Proposta Comercial - Compwire (12324355);
Anexo Habilitação Compwire (12324380);
Recurso - recorrente Primeiro Time (12344366);
Recurso - recorrente WisePath (12344367);
Anexo Contrarrazões Compwire - Recurso Primeiro Time (12363144);
Anexo Contrarrazões Compwire - Recurso WisePath (12363147);
SUMÁRIO EXECUTIVO
Trata a presente Nota Técnica de apresentar esclarecimentos da Superintendência de Tecnologia e Transformação Digital - STD quanto aos recursos apresentados pelas empresas PRIMEIRO TIME INFORMÁTICA LTDA e WISEPATH TECNOLOGIA LTDA diante do resultado do Pregão 90021/2025, o qual declarou a empresa COMPWIRE INFORMÁTICA LTDA vencedora do processo.
INFORMAÇÕES E ANÁLISE
Foram analisados e considerados os recursos apresentados, bem como os argumentos da CONTRARRAZÃO fornecidos pela empresa Compwire.
ANÁLISE 1 - DO RECURSO APRESENTADO PELA EMPRESA PRIMEIRO TIME:
Em síntese, a recorrente alega que a empresa Compwire não atende ao Subitem 4.18.6, pois ofertou produto que não atende às especificações mínimas de desempenho e performance. Abaixo detalhamento do Subitem citado:
"4.18.6. Uso máximo de CPU considerando a perda de uma controladora (por exemplo: solução com duas controladoras, uso máximo de CPU de 50%, solução com 4 controladoras, uso máximo de CPU de 75%, solução com 10 controladoras, uso máximo de CPU de 90%)."
ANÁLISE 1 - DA CONTRARRAZÃO APRESENTADA PELA EMPRESA COMPWIRE:
A Compwire, por sua vez, respondeu aos itens questionados com explicações técnicas específicas, incluindo:
A solução ofertada possui Arquitetura “symmetric active-active”, com balanceamento global de carga, cache e pools de armazenamento;
As duas controladoras operam em modo de balanceamento de carga em situações normais e assumem os serviços em cenários de falha;
As duas controladoras são interconectadas por canais espelhados RDMA;
Confiabilidade dos Dados em Cache;
Múltiplas Cópias de Cache;
Controladoras totalmente interconectadas em um mesmo gabinete de controladoras;
Após o detalhamento do funcionamento da arquitetura da Solução, a Compwire fez as seguintes considerações:
"A partir dessa arquitetura, verifica-se que, no cenário excepcional de operação com apenas uma controladora, o mecanismo de espelhamento de cache (mirrored cache) deixa de ser executado, conforme descrito na página 128 do Technical White Paper.
Essa interrupção é natural, porque não há segunda controladora para receber a cópia redundante das páginas de cache. Com isso, o sistema elimina automaticamente o overhead de processamento associado à duplicação síncrona dos dados em memória, liberando parte significativa da capacidade de CPU que, durante a operação normal, é dedicada à proteção, consistência e sincronização de cache entre controladoras.
Do ponto de vista de engenharia de desempenho, o overhead de espelhamento é um dos elementos mais custosos da operação Active-Active. Quando ele deixa de existir — exatamente no cenário de falha analisado pelo item 4.18.7 — a controladora remanescente não apenas deixa de perder performance, como passa a operar com mais capacidade líquida de CPU disponível para atender I/O, compensando a perda física da controladora par. Ou seja, o modo de operação em falha não replica linearmente o comportamento da operação normal, razão pela qual a hipótese construída pela Recorrente (divisão “50/50” da carga e queda linear de performance) não se aplica tecnicamente.
Soma-se a isso o fato de que a arquitetura da Huawei não divide IOPS de forma estática entre controladoras, ao contrário da presunção do recurso. O cache é global e espelhado, e não segmentado. O fluxo entre controladoras ocorre via RDMA Mirror Channel, tecnologia projetada para evitar gargalos e garantir failover em milissegundos, sem interrupção perceptível e sem redistribuição linear de carga.
Diante disso, a suposição de que uma controladora “sozinha” não suportaria 80% da capacidade total — conforme exige o item 4.18.7 — não reflete a arquitetura real documentada pelo fabricante, mas sim um exercício abstrato baseado em premissas inexistentes no edital e incompatíveis com o funcionamento interno do equipamento.".
Cabe registrar que os documentos citados foram apresentados para a avaliação da habilitação da empresa e foram verificados pela equipe técnica da ANAC.
AVALIAÇÃO 1 - DO RECURSO E DA CONTRARRAZÃO:
Após avaliação dos argumentos e documentação técnica, conclui-se que as evidências documentais e técnicas fornecidas foram suficientes para dirimir eventuais dúvidas levantadas pela licitante recorrente.
Dessa forma, entende-se aceitável a avaliação das informações apresentadas pela Compwire.
A documentação apresentada demonstrou que a solução ofertada atende às exigências estabelecidas no Termo de Referência, especialmente no que se refere às funcionalidades e aos requisitos técnicos demandados.
Em que pese as documentações entregues pela Compwire na fase de habilitação afastam eventuais dúvidas quanto à capacidade da solução ofertada em atender aos requisitos presentes no Edital.
ANÁLISE 2 - DO RECURSO APRESENTADO PELA EMPRESA WISEPATH:
A WisePath alega que a empresa Compwire não atendeu integralmente aos requisitos técnicos exigidos pelo edital com a solução proposta e ofertou equipamento em desacordo com as exigências editalicias.
O recurso citou os seguintes pontos como insuficientes, incompletos ou genéricos:
O equipamento deverá pertencer à modelo projetado especificamente para utilização exclusiva com dispositivos FLASH, baseados exclusivamente em memórias de estado sólido (SSD) do tipo NVMe (Subitem 4.17.9);
Incapacidade do equipamento ofertado suportar 16.000 volumes lógicos (Subitens 4.16.54.1 e 4.16.54.5);
O sistema deverá suportar, no mínimo, 16.000 (dezesseis mil) cópias (snapshots) (Subitem 4.16.54.5);
O Storage ofertado deverá suportar a expansão de sua capacidade para, no mínimo, 25% (vinte e cinco por cento) da capacidade líquida inicialmente ofertada. Esta expansão deverá ser realizada através da adição de discos e/ou gavetas de discos e deverá ser feita sem parada, migração de dados e queda de performance (Subitem 4.17.11);
Ambas as tecnologias de redução de dados: desduplicação e compressão deverão estar habilitadas simultaneamente em todos os dados do storage, sendo executada em tempo real (in-line) durante todo o teste de performance (Subitem 4.18.2);
Uso máximo de CPU considerando a perda de uma controladora (por exemplo: solução com duas controladoras, uso máximo de CPU de 50%, solução com 4 controladoras, uso máximo de CPU de 75%, solução com 10 controladoras, uso máximo de CPU de 90%)
Alternativamente ao item anterior, poderá ser comprovado que no caso de falha de uma controladora, independente da quantidade de pares ofertados, o subsistema de armazenamento não poderá perder mais que 20% da capacidade total de processamento, ou seja, a solução deverá ser dimensionada com um uso máximo de CPU de 80%.. (Subitem 4.18.7);
A interface gráfica, além de permitir o gerenciamento total da solução, deve exibir, no mínimo:
Informações de desempenho, incluindo dashboards, exibindo, pelo menos, taxas de IOPS, taxas de escrita e de leitura e tempos de resposta; (Subitem 4.16.58 e 4.16.58.2);
A interface gráfica, além de permitir o gerenciamento total da solução, deve exibir, no mínimo:
Taxa de redução obtida pelas tecnologias de desduplicação e compressão de dados (Subitem 4.16.58 e 4.16.58.4);
Deverá possuir proteção de snapshot com imutabilidade, de forma a permitir que os dados armazenados no storage permaneçam inalteráveis por um período prédeterminado (Subitem 4.16.42);
No momento da apresentação das propostas, todos os modelos dos componentes de hardware constantes da Solução deverão constar do anúncio mais recente da fabricante, não sendo aceitos equipamentos que possuam end of sale e end of support anunciados (Subitem 4.16.5);
O equipamento deverá pertencer à modelo projetado especificamente para utilização exclusiva com dispositivos FLASH, baseados exclusivamente em memórias de estado sólido (SSD) do tipo NVMe (Subitem 4.17.9);
A área utilizada para criação do Clone deverá ter o seu uso liberado após a remoção das cópias (Subitem 4.16.53.1);
O volume de origem deverá permanecer disponível para acesso, isto é, manter as atividades de leitura, alteração, deleção e alocação de novos dados para as aplicações que o estejam acessando, mesmo quando o Clone estiver sendo criado (Subitem 4.16.53.3);
ANÁLISE 2 - DA CONTRARRAZÃO APRESENTADA PELA EMPRESA COMPWIRE:
A Compwire respondeu aos itens questionados pela WisePath com explicações técnicas específicas, incluindo:
|
Item questionado pela WisePath |
Resposta da Compwire |
|
O equipamento deverá pertencer à modelo projetado especificamente para utilização exclusiva com dispositivos FLASH, baseados exclusivamente em memórias de estado sólido (SSD) do tipo NVMe (Subitem 4.17.9); |
No documento “OceanStor 2x00, 5x10 Series 6.1.x Product Description.pdf”, página 10, no qual a arquitetura de hardware da solução é apresentada de forma mais detalhada, verifica-se que a linha OceanStor Capacity Flash utiliza e somente pode ser configurada com a Smart NVMe Disk Enclosure, comprovando mais uma vez a ausência de qualquer suporte/oferta de gavetas e/ou discos SAS.
Complementando a comprovação técnica de aderência ao item 4.17.9, foi anexado à proposta o Datasheet oficial do SSD Huawei Capacity-Optimized NVMe, documento intitulado “(EN) Huawei Capacity-Optimized NVMe SSD (Applicable to OceanStor Capacity Flash Storage) Data Sheet”, que especifica, de forma inequívoca, que os SSDs utilizados na solução ofertada são exclusivamente NVMe e compatíveis somente com a linha OceanStor Capacity Flash.
Na página 2 do referido documento, a Huawei detalha, entre outros parâmetros técnicos, o Command Set e o Protocolo de Interface, declarando:
Diante da documentação oficial apresentada e da análise estritamente técnica, constata-se que:
|
|
Incapacidade do equipamento ofertado suportar 16.000 volumes lógicos (Subitens 4.16.54.1 e 4.16.54.5); |
O Termo de Referência não exige, em nenhum momento, que o storage suporte 16.000 LUNs simultâneas, razão pela qual tal interpretação não pode ser imposta retroativamente à Recorrida. Logo, ainda que a resposta tenha sido sucinta, ela não cria requisito novo e não possui força normativa para alterar ou ampliar o escopo do certame.
Além disso, há um equívoco técnico fundamental na argumentação da Recorrente: snapshots não equivalem a LUNs, nem tecnicamente, nem conceitualmente, nem operacionalmente. A tecnologia de snapshots — em qualquer fabricante enterprise (Huawei, Dell, NetApp, Hitachi, Pure, Lenovo ou IBM) — cria objetos baseados em metadados, que não geram volumes adicionais, não consomem identificadores de LUN e não impactam o limite de volumes simultâneos suportados pelo sistema.
Apenas quando um snapshot é promovido manualmente a volume independente (operação opcional e eventual) é que ele passa a constituir uma LUN — algo que o Termo de Referência não exige que ocorra para 16.000 snapshots.
Portanto, a premissa da Recorrente — de que 16.000 snapshots exigem 16.000 LUNs — é tecnicamente incorreta e não possui respaldo em nenhum documento do fabricante.
Conforme descrito na página 84 e 85 do documento “OceanStor Capacity Flash Storage 6.1.8 Technical White Paper.pdf”, o HyperCDP é uma funcionalidade nativa que utiliza tecnologia de snapshots de alta densidade para prover proteção contínua de dados (CDP).
Assim como o HyperSnap, o HyperCDP utiliza-se dos conceitos de point-in-time (TP) e Redirect-on-Write (ROW - snapshot baseado em ponteiros, que redireciona as escritas para um novo espaço em disco), porém com o diferencial de ser orquestrado de forma contínua no intervalo mínimo de 3 segundos, oferecendo proteção continua.
Ou seja, não é uma tecnologia paralela ou distinta, mas sim, evoluída a partir de snapshots, atendendo tanto ao conceito de proteção de ponto no tempo (point-in-time) de snapshots quanto ao conceito de Continuous Data Protection (CDP), conforme definido pelo próprio SNIA e citado pela própria Recorrente.
Importa destacar ainda que a própria SNIA — citada pela Recorrente, mas com trechos omitidos em sua peça recursal — fornece definição que confirma a natureza de snapshots como elementos de “ponto no tempo” (point-in-time), exatamente como utilizado nas tecnologias HyperSnap e HyperCDP da Huawei.
A nomenclatura “HyperCDP objects” é utilizada apenas para facilitar entendimento do usuário de que se trata das configurações do HyperCDP dentro da plataforma de gerenciamento da Huawei, chamada DeviceManager. Logo, isso não denota de forma alguma que o termo “objects” não esteja relacionado à funcionalidade de snapshot.
A robustez da solução é ainda mais evidente nas especificações contidas na página 85 do mesmo White Paper, onde a Huawei estabelece que o sistema suporta até 2.000.000 (dois milhões) de HyperCDP objects no total e até 60.000 por LUN, valores muito superiores ao mínimo de 16.000 snapshots exigido no item 4.16.54.5. |
|
O sistema deverá suportar, no mínimo, 16.000 (dezesseis mil) cópias (snapshots) (Subitem 4.16.54.5); |
Idem ao item anterior. |
|
O Storage ofertado deverá suportar a expansão de sua capacidade para, no mínimo, 25% (vinte e cinco por cento) da capacidade líquida inicialmente ofertada. Esta expansão deverá ser realizada através da adição de discos e/ou gavetas de discos e deverá ser feita sem parada, migração de dados e queda de performance (Subitem 4.17.11); |
Trata-se, portanto, de requisito voltado exclusivamente à capacidade de expansão da plataforma, e não à configuração inicial ofertada.
Ou seja, o Termo de Referência não restringe a expansão apenas ao preenchimento da gaveta atual, tampouco exige que todos os discos necessários à expansão de 25% estejam fisicamente presentes no equipamento no momento da proposta.
O equipamento ofertado utiliza Smart NVMe Disk Enclosures, conforme demonstrado nas respostas anteriores, sendo esta a única gaveta suportada pelo modelo 5310 Capacity Flash.
A arquitetura permite:
Outro equívoco relevante da Recorrente diz respeito ao cálculo de capacidade líquida da expansão. A WisePath presume que, para atingir os 25% exigidos pelo edital, os discos adicionais deveriam sofrer novamente desconto de paridade de RAID 6, como se a expansão fosse um novo conjunto independente. Essa interpretação é tecnicamente incorreta.
No modelo OceanStor 5310 Capacity Flash, o RAID já está estruturado na configuração inicial, e a adição de novos discos ocorre por meio da expansão do storage pool existente, não sendo criada uma nova matriz com paridades adicionais. Assim, a capacidade útil dos discos novos não sofre o mesmo impacto de overhead de paridade, pois eles passam a integrar o pool já protegido.
Considerando, portanto, os 5 slots remanescentes na gaveta atual, a simples inserção de 4 (quatro) discos de 30.72TB NVMe é plenamente suficiente para cumprir a expansão mínima de 109,25TB exigida pelo item 4.17.11.
E, ainda que isso não bastasse — hipótese meramente acadêmica — o edital expressamente permite a expansão por meio de novas gavetas, sendo possível adicionar uma Smart NVMe Disk Enclosure com até 36 SSDs NVMe, ampliando com folga a capacidade requerida. |
|
Ambas as tecnologias de redução de dados: desduplicação e compressão deverão estar habilitadas simultaneamente em todos os dados do storage, sendo executada em tempo real (in-line) durante todo o teste de performance (Subitem 4.18.2); |
No ambiente de modelagem, o valor “data reduction ratio = 1” não desabilita dedupe/compress; trata-se apenas da taxa de redução assumida para o cálculo da capacidade útil projetada, e não do estado das funcionalidades. A ativação ou desativação de dedupe/compress é configurada em outro campo do sizing, e estas funcionalidades foram marcadas como habilitadas, conforme consta do arquivo entregue.
A utilização da taxa de 1:1 foi proposital e necessária para evitar interpretação equivocada sobre a capacidade efetiva apresentada no relatório. A ferramenta de dimensionamento ajusta automaticamente a linha “Total Effective Capacity” em função da taxa de redução informada. Assim, se o fornecedor inserisse uma taxa hipotética, por exemplo, 2:1 ou 3:1, o relatório exibiria capacidade líquida artificialmente aumentada, o que poderia induzir a Administração a erro. Portanto, a taxa de redução foi mantida em 1:1 apenas para fins de cálculo de capacidade, preservando a integridade da demonstração de capacidade útil.
A interpretação da WisePath — de que “data reduction ratio = 1” significaria “funções desligadas” — demonstra desconhecimento sobre o funcionamento da plataforma Huawei e leva a conclusões incorretas. O edital exige que as funcionalidades estejam habilitadas in-line durante o teste modelado, e isso foi cumprido.
O edital não exige a apresentação de determinada taxa de redução nem vincula performance ao ganho lógico de compactação, até porque esse ganho depende de padrões de repetição de dados que variam conforme o ambiente real. |
|
Uso máximo de CPU considerando a perda de uma controladora (por exemplo: solução com duas controladoras, uso máximo de CPU de 50%, solução com 4 controladoras, uso máximo de CPU de 75%, solução com 10 controladoras, uso máximo de CPU de 90%). Alternativamente ao item anterior, poderá ser comprovado que no caso de falha de uma controladora, independente da quantidade de pares ofertados, o subsistema de armazenamento não poderá perder mais que 20% da capacidade total de processamento, ou seja, a solução deverá ser dimensionada com um uso máximo de CPU de 80%.. (Subitem 4.18.7);
|
O relatório oficial da Huawei para o cenário exigido no Termo de Referência (bloco 8KB, 70% leitura / 30% escrita, acesso randômico, cache hit limitado, desduplicação e compressão inline ativada) indica:
Para esclarecer, a documentação técnica da Huawei descreve que a linha OceanStor Capacity Flash utiliza arquitetura “symmetric active-active”, com balanceamento global de carga, cache e pools de armazenamento.
A partir dessa arquitetura, verifica-se que, no cenário excepcional de operação com apenas uma controladora, o mecanismo de espelhamento de cache (mirrored cache) deixa de ser executado, conforme descrito na página 128 do Technical White Paper. Essa interrupção é natural, porque não há segunda controladora para receber a cópia redundante das páginas de cache. Com isso, o sistema elimina automaticamente o overhead de processamento associado à duplicação síncrona dos dados em memória, liberando parte significativa da capacidade de CPU que, durante a operação normal, é dedicada à proteção, consistência e sincronização de cache entre controladoras.
Do ponto de vista de engenharia de desempenho, o overhead de espelhamento é um dos elementos mais custosos da operação Active-Active. Quando ele deixa de existir — exatamente no cenário de falha analisado pelo item 4.18.7 — a controladora remanescente não apenas deixa de perder performance, como passa a operar com mais capacidade líquida de CPU disponível para atender I/O, compensando a perda física da controladora par. Ou seja, o modo de operação em falha não replica linearmente o comportamento da operação normal, razão pela qual a hipótese construída pela Recorrente (divisão “50/50” da carga e queda linear de performance) não se aplica tecnicamente.
Soma-se a isso o fato de que a arquitetura da Huawei não divide IOPS de forma estática entre controladoras, ao contrário da presunção do recurso. O cache é global e espelhado, e não segmentado. O fluxo entre controladoras ocorre via RDMA Mirror Channel, tecnologia projetada para evitar gargalos e garantir failover em milissegundos, sem interrupção perceptível e sem redistribuição linear de carga. |
|
A interface gráfica, além de permitir o gerenciamento total da solução, deve exibir, no mínimo: Informações de desempenho, incluindo dashboards, exibindo, pelo menos, taxas de IOPS, taxas de escrita e de leitura e tempos de resposta; (Subitem 4.16.58 e 4.16.58.2); |
O documento OceanStor 6.1.x Performance Monitoring Guide.pdf é claro ao demonstrar a partir da página 420, tabela 5-129, todas as informações passíveis de consulta do equipamento. Veja-se:
|
|
A interface gráfica, além de permitir o gerenciamento total da solução, deve exibir, no mínimo: Taxa de redução obtida pelas tecnologias de desduplicação e compressão de dados (Subitem 4.16.58 e 4.16.58.4); |
O documento OceanStor 6.1.x Performance Monitoring Guide.pdf é claro ao demonstrar a partir da página 420, tabela 5-129, todas as informações passíveis de consulta do equipamento. Veja-se:
|
|
Deverá possuir proteção de snapshot com imutabilidade, de forma a permitir que os dados armazenados no storage permaneçam inalteráveis por um período prédeterminado (Subitem 4.16.42); |
Ao contrário do que a recorrente alega, a solução ofertada contempla a funcionalidade denominada Secure Snapshot, que permite definir proteção contra exclusão de snapshots, garantindo a imutabilidade dos dados por meio de políticas de retenção.
Destaca-se: “Secure Snapshot In financial, securities, or bank applications, HyperCDP objects are configured to back up critical data for long term retention. To prevent HyperCDP objects from deletion, you can set a retention period. The HyperCDP objects cannot be deleted within the retention period. After the period expires, they can be deleted manually or automatically. (…) NOTE • Secure snapshots cannot be deleted within the retention period. Given that the retention period cannot be shortened, exercise caution when configuring it. (“OceanStor Capacity Flash Storage 6.1.8 Technical White Paper.pdf, p. 85 e 86)
Ainda no mesmo documento, ratifica-se a abrangência e flexibilidade da funcionalidade:
“You can create secure snapshots for individual LUNs or file systems and secure snapshot CGs for LUN CGs. The retention period ranges from 1 day to 20 years. You can configure whether to automatically delete the snapshot upon expiration.” (“OceanStor Capacity Flash Storage 6.1.8 Technical White Paper.pdf, p. 19)
Dessa forma, é evidente que a funcionalidade Secure Snapshot impede a exclusão acidental ou maliciosa dos snapshots; garante a imutabilidade por um período pré-configurado; permite recuperação rápida dos dados originais em caso de ataque de ransomware, corrupção ou deleção, inclusive com restauração em até 3 segundos; é baseada na tecnologia de snapshot, em total alinhamento técnico com a exigência do edital. |
|
No momento da apresentação das propostas, todos os modelos dos componentes de hardware constantes da Solução deverão constar do anúncio mais recente da fabricante, não sendo aceitos equipamentos que possuam end of sale e end of support anunciados (Subitem 4.16.5); |
A Recorrente alega suposta incoerência da Recorrida ao afirmar que a Huawei já teria anunciado a nova geração da linha OceanStor Dorado (“New-Gen Dorado”). Todavia, trata-se apenas de um anúncio global, referente ao roadmap internacional do fabricante, não havendo, até o presente momento, liberação para comercialização dessa linha no Brasil pela própria Huawei. Logo, a alegação não se sustenta, pois se refere a um produto indisponível no mercado nacional.
Ademais, a linha OceanStor Dorado não pertence à mesma família de produtos ofertada no presente certame. A Recorrida apresentou a solução OceanStor Capacity Flash, cuja arquitetura, catálogo técnico, ciclo de vida e posicionamento comercial são totalmente distintos e independentes da linha OceanStor Dorado.
Assim, o anúncio global de um produto de outra família, com características, público-alvo e especificações diferentes, não guarda qualquer relação com o modelo efetivamente ofertado na licitação.
Dessa forma, reafirma-se que o modelo OceanStor 5310 Capacity Flash representa sim a última geração disponível e oficialmente comercializada pela Huawei no Brasil dentro de sua respectiva linha de produtos.
Conforme já assegurado na carta oficial da Huawei apresentada no certame — documento “Declaracao_Huawei_COMPWIRE_ANAC (HB e HGS) ASSINADA.pdf” — a própria fabricante declara expressamente que: “Todos os modelos dos componentes de hardware constantes da solução constam no anúncio mais recente da fabricante.”
Tal manifestação formal da Huawei, que é a única autoridade legítima para atestar a atualidade, disponibilidade e aderência comercial de seus produtos, reforça a plena conformidade da solução ofertada com o portfólio vigente e oficialmente divulgado pela fabricante. |
|
O equipamento deverá pertencer à modelo projetado especificamente para utilização exclusiva com dispositivos FLASH, baseados exclusivamente em memórias de estado sólido (SSD) do tipo NVMe (Subitem 4.17.9); |
No documento “OceanStor 2x00, 5x10 Series 6.1.x Product Description.pdf”, página 10, no qual a arquitetura de hardware da solução é apresentada de forma mais detalhada, verifica-se que a linha OceanStor Capacity Flash utiliza e somente pode ser configurada com a Smart NVMe Disk Enclosure, comprovando mais uma vez a ausência de qualquer suporte/oferta de gavetas e/ou discos SAS.
Complementando a comprovação técnica de aderência ao item 4.17.9, foi anexado à proposta o Datasheet oficial do SSD Huawei Capacity-Optimized NVMe, documento intitulado “(EN) Huawei Capacity-Optimized NVMe SSD (Applicable to OceanStor Capacity Flash Storage) Data Sheet”, que especifica, de forma inequívoca, que os SSDs utilizados na solução ofertada são exclusivamente NVMe e compatíveis somente com a linha OceanStor Capacity Flash.
Na página 2 do referido documento, a Huawei detalha, entre outros parâmetros técnicos, o Command Set e o Protocolo de Interface, declarando:
Diante da documentação oficial apresentada e da análise estritamente técnica, constata-se que:
|
|
A área utilizada para criação do Clone deverá ter o seu uso liberado após a remoção das cópias (Subitem 4.16.53.1); |
Para a comprovação do item 4.16.53.1, ratificamos que a área utilizada pelos Clones criados é liberada após a remoção do Clone, sob determinação do administrador, conforme a documentação, fornecida oficialmente pelo fabricante no link1 :
https://support.huawei.com/enterprise/en/doc/EDOC1100264908/d78b1a42/deleting-a-clone-pair |
|
O volume de origem deverá permanecer disponível para acesso, isto é, manter as atividades de leitura, alteração, deleção e alocação de novos dados para as aplicações que o estejam acessando, mesmo quando o Clone estiver sendo criado (Subitem 4.16.53.3); |
Em relação ao item 4.16.53.3, o volume de origem (source LUN) sempre permanece disponível para acesso dos hosts, independente do status de sincronização do Clone (Synchronizing, Sync paused, Unsynchronized ou Normal), conforme pode ser verificado no documento “OceanStor Capacity Flash Storage 6.1.8 Technical White Paper.pdf”.
“The host reads and writes the source LUN directly.” (OceanStor Capacity Flash Storage 6.1.8 Technical White Paper.pdf, p. 88 e 89)
Em tradução livre: “O host lê e grava diretamente no LUN de origem.”
É possível constatar que o acesso para leitura e escrita à LUN original é liberada instantaneamente, devido a funcionalidade HyperClone for SAN permitir a movimentação/sincronização do dado do Clone em segundo plano (background) durante seu uso. |
AVALIAÇÃO 2 - DO RECURSO E DA CONTRARRAZÃO:
Primeiramente é importante destacar que durante a fase de habilitação a equipe técnica da ANAC analisou toda a documentação enviada pela Compwire, além de realizar consultas ao site da fabricante da solução, e assim teve o entedimento de que a solução ofertada atende plenamente ao requisitos tecnológicos elencados no termo de referência.
Quanto ao item 2 do recurso interposto pela WisePath, a resposta "Sim" dada pela área técnica ao esclarecimento teve caráter estritamente funcional. A resposta confirmou que para atender ao item 4.16.54.1 do Termo de Referência a solução proposta deve tratar essas cópias como entidades lógicas endereçáveis. Isso não se confunde, em absoluto, com a criação de uma nova exigência quantitativa para suportar 16.000 LUNs simultâneas, requisito este que seria excessivo e desnecessário ao equipamento de 416 TB.
Segue abaixo questionamento realizado:
“Questionamento:
Esclarecimento 2) No item 4.16.54.5 é descrito que o sistema deve suportar no mínimo 16.000 cópias (snapshots). Já no item 4.16.54.1 é descrito que deve ser possível criar cópias de volumes permitindo operações de leitura e escrita independentes dos dados originais. Neste sentido, para permitir que o sistema seja capaz de suportar estas cópias e do mesmo modo seja capaz de convertê-las em volumes disponíveis para leitura e escrita entendemos que o sistema deve ser capaz de suportar simultaneamente no mínimo 16.000 volumes lógicos (LUNs).
Está correto nosso entendimento?
Resposta 2) Sim. O entendimento está correto”
O maior benefício esperado pela ANAC na utilização de Snapshots é a Segurança da Informação, onde seja possível aumentar a resiliência a ataques de Ransomware, recuperação rápida em caso de corrupção ou exclusão acidental, aumento da integridade dos dados (consistência), isolamento lógico dos dados e políticas de retenção e auditoria.
O item 4.16.54.1 não exige criar 16.000 LUNs, mas sim que o sistema deve permitir transformar um snapshot em uma LUN, porém, não significa que todos os 16.000 snapshots serão convertidos simultaneamente. O requisito é sobre a funcionalidade, não sobre a quantidade simultânea de LUNs resultantes desse processo.
A ANAC utiliza hoje apenas 208 LUNs em seu ambiente de produção. Exigir 16.000 LUNs seria tecnicamente absurdo, operacionalmente desnecessário e economicamente injustificável para um Storage de 416 TB úteis.
A posição da equipe técnica apenas confirmou a capacidade técnica de conversão, e não a criação de novo requisito quantitativo. Como não houve republicação do edital com ajuste do Termo de Referência e reabertura do prazo mínimo de 8 dias úteis (art. 52, § 1º, Lei 14.133/2021), fica inequívoco que a resposta ao esclarecimento não teve o condão de criar requisito novo não previsto originalmente no Termo de Referência. Ou seja, o entendimento da equipe técnica e do pregoeiro ao responder nunca foi o de que o suporte a 16.000 LUNs simultâneos seria necessário para o equipamento a ser fornecido.
Após a análise do recurso interposto pela WisePath e das respectivas contrarrazões apresentadas, conclui-se que as evidências documentais e técnicas fornecidas foram suficientes para dirimir eventuais dúvidas levantadas pela licitante recorrente.
A documentação apresentada demonstrou que a solução ofertada atende às exigências estabelecidas no Termo de Referência, especialmente no que se refere às funcionalidades e aos requisitos técnicos demandados para a prestação do serviço.
Após avaliação dos argumentos e documentação técnica, conclui-se que as evidências documentais e técnicas fornecidas foram suficientes para dirimir eventuais dúvidas levantadas pela licitante recorrente.
Dessa forma, entende-se aceitável a avaliação das informações apresentadas pela Compwire.
Em que pese as documentações entregues pela Compwire na fase de habilitação afastam eventuais dúvidas quanto à capacidade da solução ofertada em atender aos requisitos presentes no Edital.
CONCLUSÃO
As evidências e os esclarecimentos apresentados nesta Nota Técnica confirmam que todos os requisitos técnicos exigidos no Termo de Referência do Pregão Eletrônico nº 90021/2025 foram atendidos.
Dessa forma, está confirmada a adequação da proposta apresentada pela empresa recorrida, evidenciando a conformidade da solução com os parâmetros estabelecidos no edital.
Recomenda-se, assim, a manutenção da aceitação da proposta comercial apresentada pela empresa COMPWIRE INFORMÁTICA LTDA.
Submete-se o presente parecer à Gerência Técnica de Licitações e Contratos – GTLC/SAF, para as providências cabíveis.
Brasília, na data da assinatura
|
Integrante Requisitante |
Integrante Técnico |
|
FELIPE SANTOS SARMANHO
GERENTE DE INFRAESTRUTURA TECNOLÓGICA - GEIT/STD |
GUILHERME FERNANDES MENEGAZZO
ANALISTA ADMINISTRATIVO COORDENADORIA DE DATA CENTER E REDES - CDRE/GEIT
|
 | Documento assinado eletronicamente por Felipe Santos Sarmanho, Gerente de Infraestrutura Tecnológica, em 25/11/2025, às 16:46, conforme horário oficial de Brasília, com fundamento no art. 4º, do Decreto nº 10.543, de 13 de novembro de 2020. |
| | Documento assinado eletronicamente por Guilherme Fernandes Menegazzo, Analista Administrativo, em 25/11/2025, às 16:52, conforme horário oficial de Brasília, com fundamento no art. 4º, do Decreto nº 10.543, de 13 de novembro de 2020. |
 | A autenticidade deste documento pode ser conferida no site https://sei.anac.gov.br/sei/autenticidade, informando o código verificador 12366252 e o código CRC E7DBE93C. |
| Referência: Processo nº 00058.051682/2024-39 | SEI nº 12366252 |
