Resumo

  • Olooking glassda Logosys Cloud nomeia Hyderabad DC1, Mumbai DC1 e Chennai DC1, mas não identifica os edifícios, a propriedade dos racks, os circuitos, a topologia de energia ou o inventário de serviços por trás desses rótulos.
  • A APNIC atribui à Logosys Cloud oAS150636e o bloco portátil103.89.46.0/23. Em 15 de julho de 2026, oRIPEstat mostrouapenas103.89.46.0/24originado ativamente, sem espaço IPv6 visível. Essa rota era totalmente visível para os peers do RIPE RIS e tinha uma autorização RPKI válida.
  • OPeeringDB listauma porta operacional de 1 Gbps no DE-CIX Mumbai e uma instalação de interconexão, Web Werks Mumbai 1. AAPNIC identificaoAS133296como Web Werks India Pvt. Ltd.; as observações atuais de BGP tornam esse ASN a rede adjacente dominante, mas nenhum desses fatos prova que todo serviço da Logosys usa um único site ou operadora.
  • As páginas de produtos anunciam portas de até 100 Gbps, quatro pontos de presença, cinco exchanges indianas, servidores globais de streaming e colocation na Índia e nos Estados Unidos. As evidências públicas não divulgam o tamanho da frota instalada, as alocações de clientes, a capacidade site a site, a energia reservada, a capacidade de failover utilizável ou um design de recuperação multissite testado.

A página mais reveladora é a menor

A página da Logosys Cloud que mais revela sobre sua infraestrutura não é o catálogo de servidores dedicados com seus grandes números de largura de banda. É uma página de diagnóstico compacta em um hostname que começa comlg-hyderabad. Na parte superior, olooking glass da Logosysapresenta três rótulos: Hyderabad DC1, Mumbai DC1 e Chennai DC1. Ele oferece funções de ping, traceroute e arquivos de teste. A página é um sinal útil de que o operador quer que os clientes inspecionem o desempenho da rede, mas seus rótulos de cidade não são um mapa de data centers próprios. Eles não nomeiam um proprietário, um endereço, uma sala, um cage, um roteador, uma alimentação elétrica ou os SKUs de serviço disponíveis em cada cidade.

Essa distinção é importante porque o restante do catálogo da Logosys convida a uma imagem mental muito maior. Apágina de servidores dedicadosdiz que os clientes têm acesso a quatro pontos de presença e cinco exchanges de internet na Índia. Ela descreve portas padrão de 1 Gbps, 10 Gbps para servidores de alto desempenho e até 100 Gbps para um nível ultra-alto de largura de banda. Apágina de CDN de live streamingdiz que existem 20 servidores de streaming em todo o mundo. Apágina de colocationdiz que os centros estão localizados na Índia e nos Estados Unidos. Apágina sobrea empresa descreve uma oferta de nuvem de autoatendimento que inclui máquinas virtuais, computação dedicada, GPUs, armazenamento de objetos, balanceamento de carga, firewalls, VPCs, DBaaS, IPv4 reservado e backup.

Cada declaração pode descrever uma parte do portfólio de serviços. Nenhuma, por si só, diz a um comprador onde uma máquina virtual específica será executada, qual empresa possui o servidor, se dois locais anunciados compartilham um edifício ou operadora, quanta capacidade está instalada ou se a capacidade excedente permanece utilizável durante uma falha. As evidências públicas de rede dão uma resposta mais firme, mas menor. Elas estabelecem um sistema autônomo, um /24 IPv4 atualmente roteado, uma conexão de exchange nomeada e uma instalação nomeada em Mumbai.

A leitura responsável não é nem "o site é a rede" nem "tudo o que não é visível no BGP não existe". É que a cobertura do produto, o alcance lógico e a resiliência física são proposições separadas que exigem provas separadas.

Uma empresa de nuvem de 2022 com uma linhagem de radiodifusão mais antiga

A identidade legal começa em 8 de abril de 2022. Em umanúncio de incorporaçãono portal do cliente, a empresa disse que a Logosys India passava a se chamar Logosys Cloud Private Limited e forneceu o número de identificação corporativaU72900TG2022PTC161383. O aviso nomeou Ashwin Kumar como fundador e diretor administrativo e deu um endereço em Kothapet, Hyderabad. O registro da APNIC para oAS150636usa o mesmo nome de empresa e endereço de Hyderabad, o que conecta a entidade legal ao número de rede pública de forma mais direta do que apenas um nome de marca.

A história anterior a 2022 é mais complicada. A Logosys Cloud diz em sua página sobre que começou em 2013 como um provedor de computação sem contratos. Uma empresa separada, Logosys Software Solutions Private Limited, é identificada noperfil de dados corporativos da Toflercomo incorporada em 22 de março de 2013 sob o CINU72200TG2013PTC086572; o perfil lista Ashwin Kumar e Moti Singh Purohit como diretores e dá o mesmo endereço registrado em Kothapet, Hyderabad. O site da própria empresa de software comercializa produtos de playout para televisão. Ostermos de serviçoatuais da empresa de nuvem nomeiam Logosys Cloud Private Limited como o provedor de serviços, mas a cláusula de pagamentos instrui os clientes que pagam por transferência bancária, cheque ou boleto a efetuar o pagamento em favor de Logosys Software Solutions Private Limited. Os registros mostram, portanto, um endereço comum, o aparecimento de Ashwin Kumar nos registros de ambas as empresas e uma instrução de pagamento. Eles não estabelecem a participação acionária atual, a relação controladora-controlada, a propriedade de ativos ou um acordo de serviço interempresas.

Isso não é um detalhe burocrático. Um cliente que compra um servidor deve saber qual empresa assina o pedido, emite a nota fiscal, recebe os fundos, possui ou aluga o hardware, emprega a equipe de suporte e deve qualquer crédito de serviço. O anúncio de 2022 diz que produtos, serviços, site e números de contato permaneceram os mesmos após a mudança de nome, mas o aparecimento contínuo da empresa de software mais antiga como recebedora de pagamentos torna a fronteira contratual algo que vale a pena confirmar por escrito.

O registro público revisado aqui não divulga uma estrutura de grupo consolidada ou demonstrações financeiras auditadas para a operação de nuvem. A propriedade atual da Logosys Cloud além dos diretores nomeados é, portanto, desconhecida a partir das evidências disponíveis.

A linhagem de radiodifusão mais antiga, no entanto, explica por que este catálogo não é uma cópia genérica de um host commodity. A Logosys vende largura de banda de streaming, servidores remotos de playout, serviços FTP para canais de notícias, licenças de software de playout e distribuição gerenciada junto com VPS e hospedagem web. Sualistagem de playout remotocombina um servidor de 32 núcleos, 256 GB, SSDs, 10 TB de transferência e uma GPU Nvidia Quadro com o software de playout da Logosys. Este é um nicho operacional coerente: uma emissora regional pode comprar software, computação, streaming e suporte de uma única contraparte comercial. Também concentra vários modos de falha na mesma contraparte.

O que a empresa realmente vende

A Logosys Cloud abrange quatro mercados relacionados. Primeiro, hospedagem compartilhada e revenda, onde muitos clientes compartilham um servidor e dependem de um painel de controle, pilha web e equipe de suporte. Segundo, infraestrutura virtual, incluindo produtos VPS KVM e uma interface sob demanda. Terceiro, capacidade física, com servidores dedicados e colocation por unidade de rack ou rack completo. Quarto, infraestrutura de vídeo, incluindo streaming ao vivo, distribuição de CDN e playout remoto.

A amplitude é visível no portal do cliente. Suainterface de hospedagem em nuvemanuncia agrupamento de projetos, máquinas virtuais sob demanda, implantação com cloud-init, acesso ao terminal do navegador, reconstruções e uma interface REST. Essas são funções significativas do plano de controle. Elas permitem que um cliente crie e destrua computação sem esperar por um técnico, desde que o nó subjacente, armazenamento, rede e inventário de licenças existam. A página não divulga o número de hosts hypervisor, a política de overcommit, a replicação de armazenamento, as regras de posicionamento ou as regiões disponíveis no seletor.

Apágina de VPSlista planos KVM de dois a quatro núcleos, 2 GB a 8 GB de RAM e 30 GB a 240 GB de disco, com cotas mensais de transferência de até 3 TB. Ela também diz que o serviço usa servidores Dell, oferece proteção DDoS e visa 99,9% de uptime. O carrinho de compras público, no entanto, atualmente mostra apenas umStarter VPSa partir de INR 1.550 por mês e não expõe os mesmos detalhes de recursos. A página de marketing começa em INR 1.000. Um comprador não pode saber apenas por essas páginas se são diferentes gerações, localizações, preços promocionais ou simplesmente catálogos não sincronizados.

O hardware dedicado é igualmente específico no nível de SKU, mas opaco no nível de frota. A página principal lista configurações Intel E3 e E5 com uplinks de 1 Gbps e pacotes de transferência. Aentrada atual da loja de servidores dedicadosoferece 128 GB de RAM, dois SSDs de 480 GB, 10 TB a 1 Gbps e cinco endereços IP por INR 12.700 por mês. No entanto, seu título diz "48 Cores" enquanto a descrição diz um E5-2680 v4 com 28 núcleos. Essa discrepância não é evidência de capacidade indisponível, mas é motivo suficiente para exigir uma lista final de materiais em vez de tratar o título do cartão como especificação técnica.

A diferença entre uma configuração vendível e uma frota instalada é fundamental. Um cartão de produto pode ser gerado antes que o equipamento seja instalado, pode permanecer visível após o estoque se esgotar ou pode descrever hardware adquirido sob encomenda. A própria página de dedicados da Logosys marca uma configuração E5 como "Esgotado" enquanto outras configurações permanecem selecionáveis. Nenhum contador de inventário público, lista de hardware serializada, contagem de racks ou prazo de entrega estabelece quantas unidades estão instaladas e ligadas. A capacidade dedicada utilizável é desconhecida.

O mapa tem três tipos diferentes de lugar

As referências públicas a Hyderabad, Mumbai e Chennai não devem ser colocadas em um mapa sem rótulos explicando o que cada ponto significa.

Hyderabad é o local de identidade mais forte. É o endereço registrado e de contato no aviso de incorporação, nos registros da APNIC e nas políticas da empresa. O hostname do looking glass também usa Hyderabad, e a página rotula Hyderabad DC1. Mas um endereço de escritório em Kothapet não é prova de que os servidores de produção estão naquele edifício. O looking glass liga apenas a uma pesquisa de mapa no nível da cidade, não a um operador de data center nomeado ou instalação exata.

A evidência pública não estabelece se Hyderabad DC1 é uma sala própria, um cage alugado, espaço de atacado, um nó remoto ou um rótulo para serviços entregues por meio de outro operador.

Mumbai é o local de interconexão mais forte. Oregistro da Logosys no PeeringDBlistaAS150636na Web Werks Mumbai 1 e em uma porta de 1 Gbps no DE-CIX Mumbai. Oregistro da instalaçãocoloca a Web Werks Mumbai 1 no Sigma IT Park em Rabale, Navi Mumbai, e identifica quatro exchanges disponíveis no edifício. Esta é uma boa evidência de que a Logosys tem, ou pelo menos relatou, uma presença de rede operacional lá. O PeeringDB é mantido por participantes da rede em vez de servir como uma auditoria de equipamentos, portanto, não prova quantos racks, servidores ou cross-connects da Logosys estão presentes.

A Web Werks fornece contexto útil em torno do limite do edifício. Suapágina atual de data centers na Índiadescreve Mumbai 1 como uma instalação construída para esse fim de 2,3 MW com redundância N+N. Essas são alegações do operador da instalação em toda a instalação. Elas não devem ser alocadas à Logosys. Um inquilino pode ocupar uma fração de um armário ou vários racks; pode comprar um caminho de energia ou dois; pode conectar-se a uma operadora, a uma malha de exchange ou a várias redes. Nada público afirma os quilowatts contratados, o arranjo de PDU, o caminho do UPS, a cobertura do gerador, a diversidade de cross-connect ou os termos de remote hands da Logosys dentro do edifício.

Chennai é atualmente apenas um rótulo de cidade publicado pela empresa no material revisado. Nenhuma instalação nomeada em Chennai aparece no registro da Logosys no PeeringDB. Nenhum endereço, proprietário, porta de exchange, prefixo de origem ou endereço de servidor de teste foi publicado na página do looking glass. Isso não refuta um nó de serviço indireto, servidor alugado ou interconexão privada em Chennai. Significa que o status físico, operador, inventário de serviços e independência de falha de "Chennai DC1" são desconhecidos.

A própria declaração de servidor dedicado da empresa adiciona um quarto ponto de presença e cinco exchanges indianas sem nomeá-los. Sua cópia de colocation adiciona uma presença não especificada nos EUA. Essas são alegações de cobertura, não mapas de rotas. Um parceiro de CDN, provedor de trânsito, arranjo de revenda ou máquina alugada pode criar alcance de serviço sem dar à Logosys um roteador próprio ou cage em cada local. Por outro lado, um link privado ou rede de gerenciamento não anunciada pode não aparecer nos dados públicos de BGP. Rotas de fibra exatas entre quaisquer locais da Logosys não são públicas.

Não há evidência de dutos fisicamente diversos, entradas metropolitanas separadas ou caminhos de longa distância independentes.

Um /23 atribuído, um /24 visível

Os registros de recursos numéricos fornecem o limite físico mais claro. Oregistro RDAP da APNIC para o sistema autônomoidentificaAS150636como LOGOSYSCL-AS-IN, ativo na Índia e registrado em fevereiro de 2023. Oregistro de endereço da APNICatribui à Logosys Cloud a faixa IPv4 portátil103.89.46.0a103.89.47.255. Isso é um /23 contendo 512 endereços antes da sobrecarga de rede, broadcast, infraestrutura e reserva. "Portátil" significa que o bloco de endereços é atribuído ao detentor em vez de ser meramente uma sub-rede de um agregado de provedor; não significa que a empresa possui edifícios ou fibras.

No momento da observação em 15 de julho de 2026, avisão de prefixos anunciados do RIPEstatretornou apenas103.89.46.0/24. Suavisão de status de roteamentocontou 256 endereços IPv4 anunciados, nenhum prefixo IPv6 e visibilidade completa dos 326 peers IPv4 RIPE RIS no conjunto de medição. Registrou a rota vista pela primeira vez em 26 de julho de 2023. Este é um resultado operacionalmente útil: o /24 ativo não era um anúncio fraco ou apenas local naquele momento.

A segunda metade,103.89.47.0/24, tem um objeto de rota APNIC nomeandoAS150636, e o detentor tem uma autorização RPKI cobrindo o /23 com comprimento máximo de /24. Não estava presente no resultado atual de prefixos anunciados. Um objeto de rota e uma autorização de origem de rota válida são permissões e registros de política; não são evidência de que uma rota está atualmente propagada, aceita mundialmente ou carregando tráfego de clientes. O /24 não anunciado pode estar reservado, em preparação, retirado, usado privadamente ou simplesmente ocioso. A evidência pública não decide qual.

A rota ativa tem uma autorização de origem válida. Avalidação RPKI do RIPEstatencontra um ROA válido para a origemAS150636, cobrindo103.89.46.0/23com comprimento máximo /24. Isso reduz uma classe de erro de origem de rota: redes que realizam validação de origem de rota podem verificar que este AS está autorizado a originar este /24. O RPKI não valida todo o caminho AS, não prova que os pacotes chegam a um servidor saudável e não protege um serviço de falhas de energia, comutação, aplicação ou suporte.

O IPv6 permanece uma incógnita conspícua na história comercial. O PeeringDB relata zero prefixos IPv6 para a Logosys, e o RIPEstat não observou nenhum anunciado. A listagem do DE-CIX não publica um endereço IPv6 para a porta da Logosys. Um provedor ainda pode entregar IPv6 por meio de outra rede ou para clientes selecionados, mas nenhuma origem IPv6 própria é visível. Compradores que exigem dual stack nativo devem solicitar o prefixo atribuído, a política de roteamento, o processo de DNS reverso e um endereço de teste, em vez de inferir IPv6 de um rótulo genérico de nuvem.

Uma porta de peering não são cinco saídas independentes

O PeeringDB é preciso sobre a única conexão de exchange que lista: uma porta operacional de 1 Gbps no DE-CIX Mumbai, com participação em route server. Ele também classifica a rede como conteúdo, dá a ela uma política de peering aberta, registra tráfego predominantemente de saída e coloca o tráfego auto-relatado na faixa de 1-5 Gbps. A entrada foi atualizada pela última vez em dezembro de 2023. Esses campos ajudam outras redes a decidir se e onde se interconectar. Eles não são um gráfico de utilização atual, um contrato ou uma reserva de capacidade.

Uma porta de exchange de 1 Gbps tem uma taxa de linha máxima; ela não limita todo o sistema autônomo se existirem trânsito ou interconexões privadas em outros lugares. Da mesma forma, uma faixa de tráfego auto-relatada de 1-5 Gbps pode incluir tráfego fora dessa exchange. Não há contradição em princípio, mas não há medição pública vinculando a faixa de tráfego a links específicos. Um comprador não deve adicionar "1 Gbps DE-CIX" a "porta de servidor de até 100 Gbps" e assumir 101 Gbps de capacidade externa.

Velocidade de acesso ao servidor, capacidade total do fabric, compromisso de trânsito e velocidade da porta de exchange de internet medem segmentos diferentes.

A evidência de caminho atual é especialmente importante. Avisão de vizinhos do RIPEstatvêAS133296como a rede dominante diretamente antes da Logosys em centenas de caminhos de observação. Oregistro RDAP da APNIC para esse ASNo nomeiaWEBWERKS-AS-INe descreve a Web Werks India Pvt. Ltd. Oestado BGP do RIPEstat para o /24 ativotambém expõe um pequeno número de caminhos nos quais outras redes aparecem diretamente antes deAS150636, incluindo caminhos consistentes com exchange ou conectividade alternativa. Isso apoia uma conclusão medida: a Web Werks era o caminho dominante visível na época, enquanto alguma pluralidade lógica de caminhos era observável.

Isso não suporta a frase mais forte "multi-homing fisicamente redundante". Dois vizinhos BGP podem terminar no mesmo roteador, usar o mesmo conjunto de cross-connects, atravessar a mesma sala de meet-me do edifício ou depender da mesma alimentação de utilidade pública. Um route server de exchange pode expor centenas de peers por meio de uma única porta física. Vários caminhos upstream podem se reconvergir em uma única operadora além da borda do cliente. O inverso também é possível: circuitos privados podem ser fisicamente diversos, enquanto coletores públicos selecionam apenas um melhor caminho.

Para estabelecer resiliência física, a Logosys precisaria divulgar os roteadores de borda, locais de porta, operadoras, cross-connects, entradas do edifício e testes de failover relevantes para o serviço adquirido.

A declaração da empresa de cinco exchanges de internet pode se referir a redes disponíveis para clientes, malhas de exchange usadas por meio de outra parte ou conexões não listadas no PeeringDB. O registro público não nomeia as outras quatro. Até que nomes, portas e status operacional sejam fornecidos, o único attachment point de exchange rastreável independentemente nesta revisão é o DE-CIX Mumbai. Essa é uma conectividade útil, mas uma única porta de exchange não substitui o trânsito e não fornece por si só uma rota quando o edifício, roteador ou circuito de acesso falha.

Quem possui o rack, o servidor e o caminho de energia?

A Logosys usa linguagem de propriedade com cuidado em alguns lugares e de forma vaga em outros. A página de streaming diz "Rede Totalmente Própria", enquanto a página de colocation explica que os clientes podem colocar seu equipamento em um rack de IDC e que um provedor de serviços fornece energia e rede. A página de dedicados promete servidores físicos de inquilino único, mas não diz se a Logosys possui, aluga ou adquire cada servidor. O PeeringDB nomeia a Web Werks Mumbai 1 como a instalação de interconexão, não como um edifício de propriedade da Logosys.

Existem, portanto, pelo menos quatro camadas de propriedade possíveis para um serviço adquirido. A Logosys Cloud pode ser o provedor de serviços contratual. Uma empresa de data center pode possuir ou operar o edifício, UPS, geradores e refrigeração. Uma operadora ou exchange pode fornecer conectividade externa. A Logosys, o operador da instalação, um arrendador financeiro ou outro fornecedor pode possuir o servidor. O cliente controla seu sistema operacional convidado ou hardware colocado, mas pode não controlar o hypervisor, switch, array de armazenamento ou fila de remote hands.

As páginas públicas não resolvem todas as camadas para cada SKU.

Aoferta de colocation da Logosysé concreta sobre pacotes de varejo. Ela anuncia 1U a 200 W, 2U a 300 W, 4U a 400 W e 8U a 600 W, cada um com 100 GB de largura de banda. Ela também lista um rack de 1/4 a 1 kW, um rack de 1/2 a 1,5 kW e um rack completo de 42U a 3 kW. Esses são limites de produto cotados, não prova de estoque disponível em tempo real. Eles também convidam a perguntas técnicas. A página diz "Fonte de Alimentação: Sim", mas não especifica alimentações A e B, voltagem, tamanho do disjuntor, método de medição, tolerância sustentada versus pico ou tratamento de sobrecarga de fator de potência. A densidade de rack completo de 3 kW é plausível para muitas cargas de trabalho tradicionais de hospedagem, mas pode restringir implantações densas de GPU ou modernas de soquete duplo.

A mesma página de colocation chama a oferta de "data center Tier 4" perto do topo e depois descreve "data centers Tier 3". Ela não nomeia um órgão de certificação, identificador de instalação ou certificado. A terminologia Tier pode descrever ambição de design, uma abreviação do provedor ou uma certificação formal de terceiros; esses não são intercambiáveis. A única conclusão segura é que a página faz ambas as afirmações. Um comprador deve solicitar a instalação específica, certificado, escopo e validade, em vez de transferir um rótulo genérico de Tier para um rack da Logosys.

A capacidade da instalação também é fácil de interpretar mal. A Web Werks publica 2,3 MW para Mumbai 1. Esse é o número do operador da instalação para o site, não a capacidade instalada ou reservada da Logosys. Ele não diz nada sobre a fração disponível para um cliente da Logosys após carga existente, limites de refrigeração, reservas contratuais e condições de manutenção. O artigo não encontrou contagem de racks, compromisso de energia, tempo de funcionamento do gerador, contrato de combustível, design de refrigeração, estoque de peças de reposição ou inventário de servidores divulgados pela Logosys.

Capacidade instalada, ligada, operacional, vendida e utilizável em falha são todas desconhecidas no nível da empresa.

Streaming altera a cadeia de dependências

A carga de trabalho mais distinta da Logosys é o streaming de radiodifusão. Sua página de CDN ao vivo oferece planos de 1 TB e dez conexões a 5 TB e 1.000 conexões, com um canal por plano. Ela afirma menos de cinco segundos de latência para HLS e DASH, suporte para Wowza e 20 servidores de streaming em todo o mundo. A página sobre diz que a empresa atendeu mais de 100 canais de televisão. Essas são declarações comerciais de primeira parte.

Nenhuma lista pública de nós, lista de provedores, relatório de tráfego ou evidência de referência de cliente estabelece a localização e o status atuais de todos os 20 servidores ou o número ativo de clientes.

Para uma emissora, "20 servidores" não é um número de capacidade sem suposições de carga de trabalho. Um servidor recebendo um feed de contribuição de alta taxa de bits e reempacotando-o pode ter limites de CPU, GPU, armazenamento e saída muito diferentes de uma borda servindo segmentos em cache. Dez conexões a uma taxa de bits não são equivalentes a dez em outra. Uma cota mensal de transferência diz pouco sobre simultaneidade de pico. Uma CDN pode usar servidores próprios, bare metal alugado, máquinas virtuais ou um parceiro de distribuição terceirizado.

A página da Logosys não detalha as funções de origem, transcodificação, empacotamento e borda por localização.

O impacto da falha também é assimétrico. Se um nó de borda falha e o tráfego é desviado para outro lugar, os espectadores podem ver uma breve mudança de qualidade. Se a única origem ao vivo, codificador ou servidor de playout falhar, todas as bordas podem permanecer saudáveis enquanto o canal escurece. Se o painel de controle do cliente estiver indisponível, um fluxo já em execução pode continuar, mas os operadores podem não ser capazes de reiniciá-lo ou redirecioná-lo. Se um caminho upstream falhar, os servidores locais podem permanecer ligados, mas inacessíveis.

Se uma licença de gráficos ou playout falhar, a capacidade de rede e computação não restauram a saída do programa. A "redundância de CDN" precisa de um design para cada função, não apenas uma contagem de nós.

A questão do planejamento remoto é igualmente importante. Um cliente deve perguntar se seu servidor de playout e origem de streaming compartilham um host, rack, instalação ou domínio de energia; se uma instância secundária está ativa, fria ou apenas restaurável; quão atual está a cópia da mídia; e quem tem autoridade para acionar o failover. A oferta pública não fornece um objetivo de ponto de recuperação ou objetivo de tempo de recuperação. Ela diz que o suporte está disponível continuamente, mas os níveis de pessoal, metas de escalonamento e tempos de resposta de remote hands não são publicados.

Alegações de capacidade não são estados de capacidade

A palavra "capacidade" cobre pelo menos sete estados neste mercado. Capacidade de design é o que um sistema poderia suportar se construído conforme planejado. Capacidade instalada é hardware em um rack. Capacidade ligada tem um circuito energizado e alocação de refrigeração. Capacidade acesa tem um caminho de rede ativo. Capacidade operacional passa por verificações de integridade. Capacidade vendida está comprometida com clientes. Capacidade utilizável é o que resta sob a condição de falha que está sendo considerada. As páginas públicas da Logosys descrevem principalmente máximos de produto e configurações de catálogo, não esses estados.

O número de 100 Gbps na página de dedicados é uma promessa de velocidade de porta para uma classe ultra-alta de largura de banda. Não há servidor nomeado, instalação, modelo de switch, compromisso de trânsito ou preço atual anexado a ele. A listagem principal de dedicados mostra 1 Gbps. A porta de exchange do PeeringDB é de 1 Gbps. Nenhum desses números prova ou refuta os outros porque podem se referir a portas e sites diferentes. Mas uma porta de acesso de 100 Gbps não pode entregar 100 Gbps para a internet pública a menos que o resto do caminho, política de tráfego e compromisso comercial a suportem.

O inventário IPv4 ilustra outro limite. Um /23 contém 512 endereços, e apenas um /24 foi anunciado globalmente no momento da observação. A listagem de dedicados inclui cinco endereços IP por servidor. Isso não significa que a Logosys pode vender apenas cerca de 51 desses servidores: os endereços podem vir de upstreams, ser reutilizados por meio de rede privada ou ser alocados de forma diferente entre produtos. Isso significa que o espaço de endereço público e portátil é finito e parcialmente não anunciado.

Clientes que precisam de grandes alocações devem perguntar se os endereços são detidos pela Logosys ou atribuídos pelo provedor, se podem ser roteados após a migração e como o histórico de abuso e o DNS reverso são gerenciados.

Nenhum dado público de utilização mostra ocupação de CPU, alocação de RAM, consumo de armazenamento, oversubscription, utilização de porta, consumo de energia do rack ou reservas vendidas. A faixa de 1-5 Gbps do PeeringDB é auto-relatada e antiga o suficiente para exigir reconfirmação. O marcador "Esgotado" da loja de produtos em uma configuração mostra que o estado do estoque pode ser importante, mas não revela se a restrição eram processadores, drives, chassis, energia do rack ou um SKU descontinuado. O planejamento de capacidade para uma implantação real, portanto, deve começar com uma cotação datada vinculada a um site e data de entrega.

A promessa de 99,9% tem arestas processuais

A Logosys publica umacordo de nível de serviçodetalhado, o que é melhor do que deixar o uptime inteiramente para a cópia de vendas. Ele define um limite mensal de 99,9%. Em um mês de 30 dias, 0,1% equivale a cerca de 43 minutos e 12 segundos. Disponibilidade entre 99,9% e 99% rende um dia de extensão de serviço; faixas mais baixas rendem dois ou três dias, com uma fórmula abaixo de 97%. A Logosys pode, em vez disso, fornecer um crédito ou desconto equivalente a seu critério.

O remédio é mais estreito do que o título. Um cliente deve relatar a inatividade por e-mail dentro de 24 horas após descobri-la. O relógio começa quando o e-mail é enviado, não necessariamente quando a interrupção começou. Um pedido de reembolso deve então ser submetido com evidência dentro de um prazo curto após o período de faturamento. Os incidentes não são agregados para cálculos de reembolso. Trabalho planejado, manutenção de emergência e uma ampla gama de eventos externos podem ser excluídos.

As exceções incluem desempenho de exchanges de terceiros, DNS além do controle da Logosys, circuitos de acesso do cliente, redes não pertencentes à Logosys e alguns softwares ou serviços de terceiros.

Essas exclusões mapeiam diretamente para os limites da infraestrutura. A única exchange nomeada, operador de instalação e rede adjacente dominante são organizações separadas. Um cliente pode experimentar uma interrupção completa do aplicativo causada por uma falha que o contrato de serviço exclui de seu cálculo de inatividade. Isso não torna o SLA sem sentido; torna a arquitetura mais importante que a compensação. Uma extensão de um dia em um VPS barato não equivale à perda de negócios de um canal de televisão silencioso ou site de comércio indisponível.

O SLA também diz que o cliente é responsável por planos de backup e recuperação apropriados, incluindo testes periódicos, e que a Logosys não se responsabiliza pela integridade e segurança dos dados do cliente. Os termos limitam a responsabilidade cumulativa a um mês de taxas no mês anterior ao evento e excluem perdas consequentes. Clientes que exigem proteção mais forte precisam de um acordo negociado definindo disponibilidade específica do serviço, durabilidade dos dados, propriedade do backup, comunicações de incidentes, objetivos de recuperação e os componentes precisos incluídos no cálculo.

Nuvem local não significa automaticamente localidade de dados conhecida

A Logosys se apresenta como um provedor de nuvem indiano e publica preços indianos, uma identidade corporativa indiana e um sistema autônomo registrado na Índia. Esses são sinais significativos de localidade. Eles não estabelecem por si mesmos onde cada categoria de dados do cliente reside.

A página de colocation diz que existem centros na Índia e nos Estados Unidos. A página de CDN ao vivo diz que os servidores estão em todo o mundo. O portal do cliente é uma superfície de serviço separada do site de marketing. Backups, registros de monitoramento, anexos de suporte, dados DNS e bordas de streaming podem ocupar locais diferentes do nó de computação primário. Um cliente que compra hospedagem "Índia" deve exigir que o pedido de serviço declare a instalação e o país para dados primários, réplicas, backups, snapshots, logs e acesso de suporte.

Apolítica de privacidadeda empresa identifica a Logosys Cloud Private Limited e explica as categorias de informações de cliente, faturamento e uso que coleta. Ela não funciona como um cronograma de residência de dados site a site para cargas de trabalho hospedadas. Os termos colocam a responsabilidade pelos dados do cliente e conformidade legal em grande parte sobre o cliente. Para uma implantação regulamentada ou sensível à localização, a nacionalidade da marca e o código de país em um registro de IP são controles insuficientes.

A migração também testa as alegações de localidade. Uma imagem de VPS pode depender de um painel de controle proprietário, um endereço atribuído manualmente, um produto de backup local ou uma licença que não pode ser movida com o disco. Um serviço de streaming pode depender do software da Logosys, configuração Wowza e um arranjo de CDN. Apolítica de reembolsodescreve desprovisionamento de autoatendimento e provisionamento manual, faturamento contínuo até que o desprovisionamento seja confirmado e tratamento especial para nós dedicados e licenças de software. Apolítica de cancelamentoexige pelo menos sete dias de aviso antes da renovação. Nenhuma página promete um formato de exportação padrão, uma janela de transferência de dados após a rescisão ou assistência para mover um serviço ativo para outro provedor.

Como as falhas se propagariam

O teste de resiliência mais útil é começar com uma falha concreta e seguir seus efeitos.

Um evento de energia do rack ou instalação.Se um serviço é executado apenas na Web Werks Mumbai 1, um evento de PDU do rack, sala, caminho UPS ou edifício pode derrubar computação e equipamentos de borda juntos. O marketing N+N da instalação não prova que um determinado inquilino comprou alimentações duplas ou implantou equipamentos de cordão duplo. A recuperação depende de hardware sobressalente, remote hands, local de backup e se outro site tem capacidade reservada suficiente. Nada é quantificado publicamente para a Logosys.

Perda do caminho upstream dominante.As rotas globais atuais mostram predominantementeAS133296imediatamente antes da Logosys. Se essa adjacência falhar, a acessibilidade depende do status operacional e da propagação de sessões alternativas. Uma porta de route server do DE-CIX pode fornecer caminhos diretos para peers participantes, mas não é trânsito geral para todos os destinos. O número de vizinhos lógicos não revela se os links compartilham um roteador, cross-connect ou entrada do edifício.

Falha da porta de exchange ou roteador de borda.A porta DE-CIX listada é de 1 Gbps em uma instalação em Mumbai. Se o tráfego de exchange e o trânsito terminam no mesmo chassi de borda, uma falha do roteador de borda pode remover ambos mesmo quando os contratos nomeiam várias redes. Se usarem chassis e caminhos separados, a resiliência pode ser muito maior. O registro público não revela essa topologia.

Falha de hypervisor, armazenamento ou inventário.A página de hospedagem web afirma movimento automático para outro servidor quando problemas de hardware são detectados. Ela não descreve armazenamento compartilhado, lag de replicação, isolamento de falha, domínios de falha ou se cada produto VPS usa esse design. Servidores dedicados normalmente exigem reparo de componente ou um chassi de substituição, a menos que o cliente tenha um standby. Um servidor listado com RAID 1 pode tolerar uma falha de disco, mas nem toda falha de controladora, placa-mãe, energia ou erro do operador.

Falha do plano de controle.O portal do cliente lida com pedidos, faturamento, tickets e algumas ações do servidor. Uma interrupção do plano de controle pode não parar uma carga de trabalho em execução, mas pode bloquear reconstruções, acesso ao console, dimensionamento e cancelamento. Computação resiliente sem acesso resiliente e escalonamento ainda pode prolongar um incidente. A Logosys publica canais de telefone, e-mail e tickets, mas nenhuma estatística independente de resposta de suporte.

Falha de origem de streaming.Múltiplas bordas de CDN não ajudam quando o único codificador, processo de playout ou origem parou de produzir um fluxo válido. A recuperação requer uma segunda entrada, conteúdo atual, licenças, credenciais e comutação de tráfego testada. A alegação pública de "20 servidores" não identifica essas funções.

Falha de DNS ou certificado.A Logosys promove DNS redundante, mas suas páginas públicas não nomeiam provedores autoritativos por serviço ou explicam a separação de domínios de controle e falha. O DNS é explicitamente excluído do SLA quando fora do controle direto da Logosys. Os clientes devem testar a diversidade autoritativa, segurança do registrador, renovação de certificados e acesso a credenciais independentemente da conta de hospedagem.

Falha de suporte e faturamento.A economia de pequenos provedores geralmente depende de uma equipe técnica concentrada. A Logosys anuncia suporte contínuo, mas nenhum número de funcionários, escala de plantão ou tempo de escalonamento é público. A referência contínua a uma empresa de software separada nas instruções de pagamento adiciona mais uma transferência operacional a ser esclarecida. Durante um incidente, o cliente precisa de uma parte responsável autorizada a agir em todos os fornecedores de instalação, operadora, hardware e software.

A economia é atraente porque os limites ficam com o comprador

Os preços de lista da Logosys podem ser atraentes. INR 1.550 compra acesso VPS de nível básico na loja atual. INR 12.700 compra uma configuração dedicada com 128 GB de RAM, SSDs, 10 TB a 1 Gbps e cinco endereços. Uma oferta de colocation 1U começa em INR 4.500 por mês, enquanto um rack completo é listado a INR 50.000 com 3 kW. O streaming começa em INR 1.500 para um canal e 1 TB de transferência mensal. Esses preços dão a organizações menores uma rota para infraestrutura gerenciada sem os compromissos mínimos associados a um contrato de hyperscale ou atacado.

A troca econômica é que grande parte do risco de integração permanece implícito. O comprador deve precificar backups, suporte gerenciado, licenças de software, endereços extras, peças de reposição, picos de largura de banda, excessos de tráfego, remote hands, segundos sites e migração. Um preço baixo de servidor mensal não é o custo de um serviço recuperável. Para uma emissora, o denominador significativo pode ser o custo por hora de canal protegida, não o custo por núcleo. Para uma aplicação de negócios, pode ser o custo por transação recuperável ou por restauração testada.

O contrato reforça essa alocação. Os reembolsos são extensões de serviço ou créditos, não compensação por perda consequente. Os clientes devem documentar interrupções rapidamente e manter seus próprios arranjos de recuperação. Nós dedicados e licenças de software usadas têm opções limitadas de reembolso. Isso pode ser um acordo racional para cargas de trabalho não críticas, máquinas de desenvolvimento/teste, operações de mídia regional com seu próprio caminho de backup ou clientes que valorizam suporte local responsivo. É um acordo mais fraco quando um cliente assume que um rótulo de nuvem inclui durabilidade multirregião por padrão.

O que transformaria as alegações em evidências de infraestrutura

A Logosys poderia tornar sua oferta pública muito mais fácil de avaliar sem divulgar detalhes sensíveis de rede. A primeira melhoria seria uma matriz de localização datada. Cada cidade deve nomear o operador da instalação, classes de serviço disponíveis, se a capacidade é própria ou alugada e se o site está aceitando novos pedidos. Um mapa deve distinguir escritório, região de nuvem, borda de CDN, porta de exchange e sala de colocation. Linhas entre cidades devem aparecer apenas onde uma rota física e operador são conhecidos; caso contrário, o mapa deve mostrar alcance de serviço em vez de fibra implícita.

A segunda melhoria seria uma página de fatos de rede. Ela poderia listar prefixos ativos, status IPv6, provedores de trânsito, exchanges, capacidades de porta, endereços de looking glass e cobertura RPKI, com uma data da última atualização. Deve afirmar se múltiplas sessões estão em roteadores separados e se entram na instalação através de caminhos diversos. O registro atual do PeeringDB é útil, mas foi atualizado materialmente pela última vez em 2023 e nomeia apenas uma exchange e uma instalação.

A terceira seria um vocabulário de capacidade. A Logosys não precisa publicar utilização sensível ao cliente, mas poderia separar servidores instalados de configurações encomendáveis, taxa de linha de porta de largura de banda de internet comprometida, energia do edifício de energia do inquilino e capacidade normal de capacidade excedente utilizável em falha. Para colocation, uma cotação deve declarar número de alimentações, classificação do disjuntor, voltagem, energia incluída, medição, cross-connects e termos de remote hands.

Para nuvem, deve declarar geração do host, durabilidade do armazenamento, política de overcommit e cobertura de migração ao vivo.

A quarta seriam evidências de recuperação específicas do serviço. A empresa poderia publicar se as instâncias VPS são reinicializáveis em outro nó, se os backups permanecem na mesma instalação, como funcionam o failover de origem e borda de streaming e o que os clientes devem fornecer. Um histórico de status deve identificar incidentes por serviço e região, protegendo os detalhes do cliente. Um exercício de failover bem-sucedido com data, escopo e tempo de recuperação medido diria mais do que um ícone genérico de redundância.

Para compradores avaliando a Logosys hoje, a lista de diligência é direta:

  1. Coloque a entidade legal exata de contratação e faturamento no formulário de pedido, incluindo o papel da Logosys Software Solutions Private Limited.
  2. Nomeie a instalação e o país para computação, armazenamento primário, réplicas, backups, logs e acesso de suporte.
  3. Identifique quem possui o servidor, rack, alimentação elétrica, cross-connect e espaço IP usado pelo serviço adquirido.
  4. Obtenha detalhes ativos de trânsito e exchange e pergunte quais links são fisicamente independentes e teste o failover.
  5. Converta cada alegação de largura de banda em porta, compromisso, política de pico, cota de transferência e responsabilidade de congestionamento.
  6. Converta cada alegação de capacidade em quantidades instaladas, ligadas, operacionais, disponíveis para pedido e utilizáveis em falha.
  7. Defina a propriedade do backup, formato de exportação, teste de restauração, ponto de recuperação, tempo de recuperação e assistência de saída.
  8. Reconcilie a configuração de marketing, a configuração do carrinho de compras e a lista final de materiais antes do pagamento.
  9. Negocie notificação de incidentes e créditos de serviço em torno do impacto real do negócio, em vez da página genérica de 99,9%.
  10. Exija evidências para Hyderabad, Chennai, o quarto ponto de presença, quatro exchanges adicionais e qualquer local nos EUA se o design proposto depender deles.

A conclusão

A Logosys Cloud não é meramente um host web com uma palavra de nuvem anexada. Ela tem uma rede indiana registrada, proteção de origem de rota válida, uma interconexão visível em Mumbai, controles de autoatendimento, ofertas de servidores físicos e uma especialização credível em playout de televisão e streaming. Para emissoras regionais e clientes indianos menores, essa combinação pode ser comercialmente útil.

Mas a história da infraestrutura pública ainda não é tão ampla quanto a história do produto. O looking glass de três cidades não revela três instalações independentes. O /23 atribuído não significa que ambos os /24 sejam roteados. Uma porta de exchange de 1 Gbps não prova cinco conexões de exchange ou um caminho de internet de 100 Gbps. Uma instalação de 2,3 MW não dá à Logosys 2,3 MW. Vinte servidores de streaming não estabelecem vinte origens independentes. Um SLA de 99,9% não garante recuperação de eventos de instalação, trânsito, plano de controle ou perda de dados.

As evidências apoiam uma conclusão limitada. A Logosys Cloud controla oAS150636, origina ativamente um /24 bem visível e válido por RPKI, e relata uma presença operacional na Web Werks Mumbai 1 e no DE-CIX Mumbai. Hyderabad está firmemente estabelecida como sua base corporativa e operacional, enquanto Chennai e o restante da pegada anunciada permanecem insuficientemente especificados. Tudo além desse limite deve ser comprado através de um pedido específico do site, específico da capacidade e específico da recuperação, não inferido do catálogo. A próxima prova significativa não será um número maior de largura de banda, mas uma declaração datada de onde o serviço é executado, o que permanece disponível quando ele falha e quem é responsável por colocá-lo de volta.