Resumo
- O própriolooking glass de rededa Logosys Cloud nomeia Hyderabad DC1, Mumbai DC1 e Chennai DC1, mas não identifica os prédios, a propriedade dos racks, circuitos, topologia de energia ou inventário de serviços por trás desses rótulos.
- A APNIC atribui à Logosys Cloud o
AS150636e o bloco portátil103.89.46.0/23. Em 15 de julho de 2026,RIPEstat mostrouapenas103.89.46.0/24originado ativamente, sem espaço IPv6 visível. Essa rota estava totalmente visível para os peers RIPE RIS e tinha uma autorização RPKI válida. - PeeringDB listauma porta operacional de 1 Gbps no DE-CIX Mumbai e uma instalação de interconexão, Web Werks Mumbai 1.APNIC identifica
AS133296como Web Werks India Pvt. Ltd.; observações atuais de BGP tornam esse ASN a rede adjacente dominante, mas nenhum fato prova que cada serviço da Logosys usa um único site ou uma única operadora. - As páginas de produtos anunciam até portas de 100 Gbps, quatro pontos de presença, cinco exchanges indianas, servidores de streaming globais e colocation na Índia e nos Estados Unidos. Evidências públicas não divulgam o tamanho da frota instalada, alocações de clientes, capacidade por site, energia reservada, capacidade de failover utilizável ou um projeto testado de recuperação multissite.
A página mais reveladora é a menor
A página da Logosys Cloud que mais diz sobre sua infraestrutura não é o catálogo de servidores dedicados com seus grandes números de largura de banda. É uma página compacta de diagnóstico 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 arquivo de teste. A página é um sinal útil de que a operadora deseja que os clientes inspecionem o desempenho da rede, mas seus rótulos de cidade não são um mapa de data centers de propriedade. Eles não nomeiam um proprietário, um endereço, uma sala, uma gaiola, um roteador, uma alimentação de energia 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 em toda a Índia. Ela descreve portas padrão de 1 Gbps, 10 Gbps para servidores de alto desempenho e até 100 Gbps para um nível de largura de banda ultra-alta. Apágina de CDN de transmissão ao vivodiz que há 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 sobreda empresa descreve uma nuvem de autosserviço que oferece máquinas virtuais, computação dedicada, GPUs, armazenamento de objetos, balanceamento de carga, firewalls, VPCs, DBaaS, IPv4 reservado e backup.
Cada afirmação pode descrever uma parte do portfólio de serviços. Nenhuma, por si só, informa a um comprador onde uma máquina virtual específica será executada, qual empresa é proprietária do servidor, se dois locais anunciados compartilham um prédio ou operadora, quanta capacidade está instalada ou se a capacidade ociosa permanece utilizável durante uma falha. As evidências da rede pública dão uma resposta mais firme, porém 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 é "o site é a rede" nem "tudo que não é visível no BGP não existe". É que cobertura de produto, alcance lógico e resiliência física são proposições separadas que exigem provas separadas.
Uma empresa de nuvem de 2022 com uma linhagem de transmissã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 ser Logosys Cloud Private Limited e forneceu o número de identificação corporativaU72900TG2022PTC161383. O aviso nomeou Ashwin Kumar como fundador e diretor administrativo e forneceu um endereço em Kothapet, Hyderabad. O registro da APNIC paraAS150636usa o mesmo nome da empresa e endereço de Hyderabad, o que conecta a entidade legal ao número de rede pública mais diretamente do que um nome de marca sozinho faria.
A história antes de 2022 é mais complicada. A Logosys Cloud diz em sua página 'sobre' que começou em 2013 como um provedor de computação sem contrato. Uma empresa separada, Logosys Software Solutions Private Limited, é identificada noperfil de dados corporativos da Toflercomo constituída em 22 de março de 2013 sob o CINU72200TG2013PTC086572; o perfil lista Ashwin Kumar e Moti Singh Purohit como diretores e fornece o endereço registrado em Kothapet, Hyderabad. O próprio site da empresa de software comercializa produtos de playout de televisão. Os atuaistermos de serviçoda empresa de nuvem nomeiam a Logosys Cloud Private Limited como a provedora de serviços, mas a cláusula de pagamentos instrui os clientes que pagam por transferência bancária, cheque ou ordem de pagamento a efetuar o pagamento em favor da Logosys Software Solutions Private Limited. Portanto, os registros mostram um endereço comum, a aparição 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, o status de controladora-subsidiária, a propriedade de ativos ou um acordo de serviço entre empresas.
Isso não é trivialidade administrativa. 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 a aparição contínua da empresa de software mais antiga como destinatária de pagamentos deixa a fronteira contratual valendo a pena confirmar por escrito.
O registro público analisado aqui não divulga uma estrutura de grupo consolidada ou demonstrações financeiras auditadas para a operação de nuvem. Portanto, a propriedade atual da Logosys Cloud além dos diretores nomeados é desconhecida a partir das evidências disponíveis.
A linhagem de transmissão mais antiga, no entanto, explica por que este catálogo não é uma cópia genérica de um host de commodities. A Logosys vende largura de banda para streaming, servidores de playout remoto, serviços de FTP para canais de notícias, licenças de software de playout e distribuição gerenciada, juntamente com VPS e hospedagem web. Sualista de playout remotocombina um servidor de 32 núcleos, 256 GB de RAM, 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. O primeiro é hospedagem compartilhada e revenda, onde muitos clientes compartilham um servidor e dependem de um painel de controle, stack web e equipe de suporte. O segundo é infraestrutura virtual, incluindo produtos VPS KVM e uma interface sob demanda. O terceiro é capacidade física, com servidores dedicados e colocation por unidade de rack ou rack completo. O quarto é infraestrutura de vídeo, incluindo transmissão ao vivo, distribuição 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 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, replicação de armazenamento, 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 franquias de transferência mensais de até 3 TB. Ela também diz que o serviço usa servidores Dell, oferece proteção DDoS e tem meta de 99,9% de uptime. O carrinho de compras público, no entanto, atualmente mostra apenas umVPS Startera partir de INR 1.550 por mês e não expõe o mesmo detalhamento de recursos. A página de marketing começa em INR 1.000. Um comprador não pode dizer apenas por essas páginas se são gerações diferentes, localidades, 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 da frota. A página principal lista configurações Intel E3 e E5 com uplinks de 1 Gbps e pacotes de transferência. A atualentrada 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 Núcleos", 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 uma 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 montado no rack, pode permanecer visível após o esgotamento do estoque ou pode descrever hardware adquirido sob encomenda. A própria página de dedicados da Logosys marca uma configuração E5 como "Esgotada" 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 energizadas. A capacidade dedicada utilizável é desconhecida.
O mapa tem três tipos diferentes de lugar
Referências públicas a Hyderabad, Mumbai e Chennai não devem ser colocadas em um único 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, registros da APNIC e 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 servidores de produção estejam nesse prédio. O looking glass vincula apenas a uma pesquisa de mapa em nível de cidade, não a um operador de data center nomeado ou instalação exata.
As evidências públicas não estabelecem se Hyderabad DC1 é uma sala própria, uma gaiola alugada, espaço de atacado, um nó remoto ou um rótulo para serviços entregues por meio de outra operadora.
Mumbai é o local de interconexão mais forte.O registro da Logosys no PeeringDBlistaAS150636no Web Werks Mumbai 1 e em uma porta de 1 Gbps no DE-CIX Mumbai. Oregistro da instalaçãocoloca o Web Werks Mumbai 1 no Sigma IT Park em Rabale, Navi Mumbai, e identifica quatro exchanges disponíveis no prédio. Esta é uma boa evidência de que a Logosys tem, ou pelo menos relatou, uma presença operacional de rede ali. 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 um contexto útil em torno dos limites do prédio. Sua atualpágina de data centers na Índiadescreve Mumbai 1 como uma instalação construída sob medida de 2,3 MW com redundância N+N. Essas são alegações do operador da instalação. Elas não devem ser atribuídas à Logosys. Um locatário pode ocupar uma fração de um gabinete ou vários racks; pode comprar um caminho de energia ou dois; pode se conectar a uma operadora, um fabric de exchange ou várias redes. Nada público declara os kilowatts contratados, o arranjo de PDUs, o caminho de UPS, a cobertura do gerador, a diversidade de cross-connects ou os termos de mãos remotas da Logosys dentro do prédio.
Chennai é atualmente apenas um rótulo de cidade publicado pela empresa no material analisado. Nenhuma instalação nomeada de Chennai aparece no registro PeeringDB da Logosys. 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 falhas do "Chennai DC1" são desconhecidos.
A declaração da própria empresa sobre servidores dedicados adiciona um quarto ponto de presença e cinco exchanges indianas sem nomeá-las. 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 CDN, provedor de trânsito, arranjo de revenda ou máquina alugada pode criar alcance de serviço sem dar à Logosys um roteador ou gaiola própria 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. As 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 metro 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 rígido mais claro.O registro RDAP da APNIC para o sistema autônomoidentificaAS150636como LOGOSYSCL-AS-IN, ativo na Índia e registrado em fevereiro de 2023.O registro de endereço da APNICatribui à Logosys Cloud a faixa IPv4 portátil103.89.46.0até103.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 titular, em vez de ser meramente uma sub-rede de um agregado de provedor; isso não significa que a empresa possua prédios ou fibras.
No momento da observação, em 15 de julho de 2026,a visualização de prefixos anunciados do RIPEstatmostrou apenas103.89.46.0/24. Suavisualização de status de roteamentocontou 256 endereços IPv4 anunciados, nenhum prefixo IPv6 e visibilidade completa dos 326 peers IPv4 RIPE RIS do 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 da APNIC nomeandoAS150636, e o titular 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; eles não são evidências de que uma rota seja atualmente propagada, aceita globalmente ou transportando tráfego de clientes. O /24 não anunciado pode estar reservado, em fase de preparação, retirado, usado privadamente ou simplesmente ocioso. As evidências públicas não determinam qual é o caso.
A rota ativa tem uma autorização de origem válida.A validação RPKI do RIPEstatencontra um ROA válido para 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 alcancem um servidor saudável nem protege um serviço contra falhas de energia, comutação, aplicação ou suporte.
O IPv6 permanece um desconhecido notável na história comercial. O PeeringDB relata zero prefixos IPv6 para a Logosys, e o RIPEstat não observou nenhum anunciado. A lista 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 pilha dupla nativa 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 a partir de um rótulo genérico de nuvem.
Uma porta de peering nã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 do servidor de rotas. Ele também classifica a rede como conteúdo, atribui uma política de peering aberta, registra tráfego majoritariamente de saída e coloca o tráfego autorrelatado 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 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 banda de tráfego autorrelatada 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 banda de tráfego a links específicos. Um comprador não deve somar "1 Gbps DE-CIX" a "até 100 Gbps de porta de servidor" e assumir 101 Gbps de capacidade externa.
A velocidade de acesso ao servidor, a capacidade agregada do fabric, o compromisso de trânsito e a velocidade da porta de IX medem segmentos diferentes.
As evidências de caminho atuais são especialmente importantes.A visã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 ASNnomeia-oWEBWERKS-AS-INe descreve Web Werks India Pvt. Ltd. Oestado BGP para o /24 ativodo RIPEstat também expõe um pequeno número de caminhos em que outras redes aparecem diretamente antes deAS150636, incluindo caminhos consistentes com exchange ou conectividade alternativa. Isso apoia uma conclusão medida: Web Werks era o caminho visível dominante no momento, enquanto alguma pluralidade de caminhos lógicos era observável.
Ela não apoia a frase mais forte "multi-homing fisicamente redundante". Dois vizinhos BGP podem terminar no mesmo roteador, usar o mesmo feixe de cross-connect, atravessar a mesma sala de meet-me do prédio ou depender da mesma alimentação de utilidade. Um servidor de rotas de exchange pode expor centenas de peers através de uma porta física. Vários caminhos AS upstream podem reconvergir em uma 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, localizações de porta, operadoras, cross-connects, entradas de prédio e testes de failover relevantes para o serviço adquirido.
A declaração da empresa sobre cinco exchanges de internet pode se referir a redes disponíveis para clientes, fabrics de exchange usados por meio de terceiros 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, a única conexão de exchange rastreável independentemente nesta análise é o DE-CIX Mumbai. Essa é uma conectividade útil, mas uma porta de exchange não é substituta para trânsito e não fornece, por si só, uma rota quando o prédio, roteador ou circuito de acesso falha.
Quem é proprietário do rack, servidor e 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" (Fully Own Network), enquanto a página de colocation explica que os clientes podem colocar seus equipamentos 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 locação única, mas não diz se a Logosys possui, aluga ou adquire cada servidor. O PeeringDB nomeia Web Werks Mumbai 1 como a instalação de interconexão, não como um prédio de propriedade da Logosys.
Há, portanto, pelo menos quatro camadas possíveis de propriedade para um serviço adquirido. A Logosys Cloud pode ser a provedora contratual de serviços. Uma empresa de data center pode possuir ou operar o prédio, 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 ser dono do 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 mãos remotas. As páginas públicas não resolvem todas as camadas para cada SKU.
Aoferta de colocation da Logosysé concreta sobre os pacotes de varejo. 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. Também lista um quarto de rack a 1 kW, meio rack a 1,5 kW e um rack completo de 42U a 3 kW. Esses são limites de produto cotados, não prova de inventário ocioso disponível. Eles também convidam a perguntas técnicas. A página diz "Fonte de Alimentação: Sim", mas não especifica as alimentações A e B, tensão, tamanho do disjuntor, método de medição, tolerância sustentada versus pico ou tratamento da sobrecarga do fator de potência. A densidade de rack completo de 3 kW é plausível para muitas cargas de trabalho de hospedagem tradicionais, mas pode restringir implantações densas de GPU ou servidores modernos de dois soquetes.
A mesma página de colocation chama a oferta de "Data Center Tier 4" perto do topo e, mais tarde, descreve "Data Centers Tier 3". Ela não nomeia um organismo de certificação, identificador de instalação ou certificado. A terminologia de tier pode descrever ambição de design, uma abreviação do provedor ou uma certificação formal de terceiros; essas não são intercambiáveis. A única conclusão segura é que a página faz ambas as alegações. Um comprador deve solicitar a instalação específica, certificado, escopo e expiração, em vez de transferir um rótulo de tier genérico 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. Não diz nada sobre a fração disponível para um cliente da Logosys após a carga existente, limites de refrigeração, reservas contratuais e condições de manutenção. O artigo não encontrou divulgação do número de racks da Logosys, compromisso de energia, tempo de execução do gerador, contrato de combustível, projeto de refrigeração, estoque de peças sobressalentes ou inventário de servidores.
A capacidade instalada, energizada, operacional, vendida e utilizável em caso de falha são todas desconhecidas no nível da empresa.
O streaming altera a cadeia de dependência
A carga de trabalho mais distinta da Logosys é o streaming de transmissã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. Alega menos de cinco segundos de latência para HLS e DASH, suporte a Wowza e 20 servidores de streaming em todo o mundo. A página 'sobre' diz que a empresa atendeu a mais de 100 canais de televisão. Essas são declarações comerciais primárias. Nenhuma lista de nós pública, lista de provedores, relatório de tráfego ou evidência de referência de clientes estabelece a localização e o status atuais de todos os 20 servidores ou a contagem de clientes ativos.
Para uma emissora, "20 servidores" não é um número de capacidade sem premissas de carga de trabalho. Um servidor recebendo um feed de contribuição de alta taxa de bits e reempacotando 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 a outra. Uma cota de transferência mensal diz pouco sobre a concorrência 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, empacotador e borda por localização.
O impacto da falha também é assimétrico. Se um nó de borda falhar e o tráfego for redirecionado para outro lugar, os espectadores podem ver uma breve alteração de qualidade. Se a única origem ao vivo, codificador ou servidor de playout falhar, cada borda pode permanecer saudável enquanto o canal fica escuro. Se o painel de controle do cliente estiver indisponível, um stream já em execução pode continuar, mas os operadores podem ser incapazes de reiniciá-lo ou redirecioná-lo. Se um caminho upstream falhar, os servidores locais podem permanecer energizados, 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. "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á quente, fria ou meramente restaurável; quão atual é 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. Diz que o suporte está disponível continuamente, mas os níveis de pessoal, metas de escalonamento e tempos de resposta de mãos remotas não são publicados.
Alegações de capacidade não são estados de capacidade
A palavra "capacidade" abrange 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 energizada tem um circuito energizado e alocação de refrigeração. Capacidade iluminada tem um caminho de rede ativo. Capacidade operacional passa em verificações de saúde. Capacidade vendida está comprometida com clientes. Capacidade utilizável é o que permanece sob a condição de falha 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 de largura de banda ultra-alta. Não há servidor nomeado, instalação, modelo de switch, compromisso de trânsito ou preço atual vinculado a ele. A principal lista de dedicados compráveis mostra 1 Gbps. A porta de exchange no 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 à internet pública a menos que o restante do caminho, política de tráfego e compromisso comercial o 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 lista de dedicados inclui cinco endereços IP por servidor. Isso não significa que a Logosys possa vender apenas cerca de 51 desses servidores: os endereços podem vir de upstreams, ser reutilizados por meio de redes privadas ou alocados de forma diferente entre produtos. 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 mantidos 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, sobrescritura, utilização de porta, consumo de energia do rack ou reservas vendidas. A banda de 1-5 Gbps do PeeringDB é autorrelatada e antiga o suficiente para exigir reconfirmação. O marcador "Esgotado" na loja de produtos em uma configuração mostra que o estado do estoque pode importar, mas não revela se a restrição foram processadores, unidades, 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 procedimentais
A Logosys publica umacordo de nível de serviçodetalhado, o que é melhor do que deixar o uptime totalmente para o texto 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 o tempo de inatividade por e-mail dentro de 24 horas após descobri-lo. O relógio começa quando o e-mail é enviado, não necessariamente quando a interrupção começou. Uma solicitação de reembolso deve então ser enviada com evidências em um prazo curto após o período de cobrança. Os incidentes não são agregados para cálculos de reembolso. Trabalhos planejados, 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 fora 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 tempo de inatividade. Isso não torna o SLA sem sentido; torna a arquitetura mais importante do 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 assume responsabilidade pela integridade e segurança dos dados do cliente. Os termos limitam a responsabilidade cumulativa às taxas de um mês no mês anterior ao evento e excluem perdas consequenciais. 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 uma provedora de nuvem indiana 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 só, 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 localizações diferentes do nó de computação primário. Um cliente que compra hospedagem "Índia" deve exigir que a ordem de serviço declare a instalação e o país para dados primários, réplicas, backups, snapshots, logs e acesso ao suporte.
Apolítica de privacidadeda empresa identifica a Logosys Cloud Private Limited e explica as categorias de informações do cliente, cobrança e uso que coleta. Ela não funciona como um cronograma de residência de dados por site para cargas de trabalho hospedadas. Os termos colocam a responsabilidade pelos dados do cliente e conformidade legal em grande parte no cliente. Para uma implantação regulamentada ou sensível à localização, a nacionalidade da marca e o código do país em um registro de IP são controles insuficientes.
A migração também testa as alegações de localidade. Uma imagem 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 se mover 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 o desprovisionamento por autosserviço e provisionamento manual, cobrança contínua até que o desprovisionamento seja confirmado e tratamento especial para nós comprometidos e licenças de software. Apolítica de cancelamentoexige aviso prévio de pelo menos sete dias antes da renovação. Nenhuma das páginas promete um formato de exportação padrão, uma janela de transferência de dados após o término 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 no rack ou instalação.Se um serviço roda apenas no Web Werks Mumbai 1, um PDU de rack, sala, caminho de UPS ou evento no prédio pode derrubar equipamentos de computação e borda de rede juntos. O marketing N+N da instalação não prova que um locatário específico comprou alimentações duplas ou implantou equipamentos com cabos duplos. A recuperação depende de hardware sobressalente, mãos remotas, local de backup e se outro site tem capacidade reservada suficiente. Nada disso está 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 alcançabilidade depende do status operacional e da propagação de sessões alternativas. Uma porta de servidor de rotas 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 de prédio.
Falha da porta de exchange ou roteador de borda.A porta DE-CIX listada é de 1 Gbps em uma instalação de Mumbai. Se o tráfego de exchange e o trânsito terminarem no mesmo chassi de borda, uma falha no 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 mais forte. O registro público não revela essa topologia.
Falha de hypervisor, armazenamento ou inventário.A página de hospedagem web alega movimentação automática para outro servidor quando problemas de hardware são detectados. Ela não descreve armazenamento compartilhado, atraso de replicação, fencing, 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 unidade, mas não todos os erros de controlador, placa-mãe, energia ou operador.
Falha do plano de controle.O portal do cliente lida com pedidos, cobrança, 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, escalonamento e cancelamento. Computação resiliente sem acesso e escalonamento resilientes 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 stream 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 esses papéis.
Falha de DNS ou certificado.A Logosys promove DNS redundante, mas suas páginas públicas não nomeiam provedores autoritativos por serviço nem explicam a separação de domínios de controle e falha. O DNS é explicitamente excluído do SLA quando está fora do controle direto da Logosys. Os clientes devem testar a diversidade autoritativa, a segurança do registrador, a renovação de certificados e o acesso às credenciais independentemente da conta de hospedagem.
Falha de suporte e cobrança.A economia de pequenos provedores muitas vezes depende de uma equipe técnica concentrada. A Logosys anuncia suporte contínuo, mas nenhuma contagem de pessoal, escala de sobreaviso ou tempos de escalonamento são públicos. A referência contínua a uma empresa de software separada nas instruções de pagamento adiciona outra transferência operacional a ser esclarecida. Durante um incidente, o cliente precisa de uma parte responsável capacitada para agir entre instalação, operadora, hardware e fornecedores de software.
A economia é atraente porque os limites ficam com o comprador
Os preços de tabela 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 hyperscale ou de atacado.
A contrapartida 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, rajadas de largura de banda, excessos de tráfego, mãos remotas, segundos sites e migração. Um baixo preço mensal de servidor 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 perdas consequenciais. Os clientes devem documentar as interrupções rapidamente e manter seus próprios arranjos de recuperação. Nós comprometidos e licenças de software usadas têm opções limitadas de reembolso. Isso pode ser um negócio racional para cargas de trabalho não críticas, máquinas de desenvolvimento/teste, operações de mídia regionais com seu próprio caminho de backup ou clientes que valorizam suporte local responsivo.
É um negócio 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 da rede. A primeira melhoria seria uma matriz de localização datada. Cada cidade deve nomear o operador da instalação, as 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 CDN, porta de exchange e sala de colocation. As linhas entre cidades devem aparecer apenas onde uma rota física e operadora são conhecidas; caso contrário, o mapa deve mostrar o alcance do serviço em vez de fibra implícita.
A segunda melhoria seria uma página de fatos da rede. Ela poderia listar prefixos ativos, status de 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 declarar se várias sessões estão em roteadores separados e se elas entram na instalação por caminhos diversos. O registro atual no PeeringDB é útil, mas foi atualizado pela última vez materialmente 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 a utilização sensível do cliente, mas poderia separar servidores instalados de configurações encomendáveis, taxa de linha da porta da largura de banda de internet comprometida, energia do prédio da energia do locatário e capacidade normal da capacidade ociosa utilizável em falha. Para colocation, uma cotação deve declarar a contagem de alimentações, classificação do disjuntor, tensão, energia incluída, medição, cross-connects e termos de mãos remotas.
Para nuvem, deve declarar a geração do host, durabilidade do armazenamento, política de overcommit e cobertura de migração ao vivo.
A quarta seria evidência de recuperação específica do serviço. A empresa poderia publicar se as instâncias VPS são reiniciá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:
- Coloque a entidade legal exata de contratação e faturamento no formulário de pedido, incluindo o papel da Logosys Software Solutions Private Limited.
- Nomeie a instalação e o país para computação, armazenamento primário, réplicas, backups, logs e acesso ao suporte.
- Identifique quem é proprietário do servidor, rack, alimentação de energia, cross-connect e espaço IP usado pelo serviço adquirido.
- Obtenha detalhes ativos de trânsito e exchange, depois pergunte quais links são fisicamente independentes e teste o failover.
- Converta cada alegação de largura de banda em uma porta, compromisso, política de rajada, franquia de transferência e responsabilidade por congestionamento.
- Converta cada alegação de capacidade em quantidades instaladas, energizadas, operacionais, disponíveis para pedido e utilizáveis em falha.
- 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.
- Reconcilie a configuração de marketing, a configuração do carrinho de compras e a lista final de materiais antes do pagamento.
- Negocie a notificação de incidentes e créditos de serviço com base no impacto real do negócio, em vez da página genérica de 99,9%.
- Exija evidências para Hyderabad, Chennai, o quarto ponto de presença, quatro exchanges adicionais e qualquer local nos EUA se o projeto proposto depender deles.
O resultado final
A Logosys Cloud não é meramente um host web com uma palavra de nuvem anexada. Ela tem uma rede indiana registrada, proteção válida de origem de rota, uma interconexão visível em Mumbai, controles de autosserviço, 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 divulga três instalações independentes. O /23 atribuído não significa que ambos os /24 estão 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 controlaAS150636, origina ativamente um /24 bem visível e válido em RPKI, e relata uma presença operacional no Web Werks Mumbai 1 e 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 adquirido por meio de um pedido específico de local, capacidade e 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 roda, o que permanece disponível quando falha e quem é responsável por recolocá-lo no ar.