Resumo
- A página jurídica atual da Servercore destinada aos clientes nomeia contratantes locais no Cazaquistão, Uzbequistão e Quênia, enquanto os serviços russos são documentados sob a JSC Selectel; um catálogo comum de infraestrutura ou interface não apaga essa cisão contratual.
- A Rússia possui a pegada física mais profunda divulgada, mas os megawatts conectados, os números de racks e os rótulos de zonas de disponibilidade não revelam a energia de reserva, a ocupação, o estoque, a diversidade de rotas ou a capacidade que um cliente específico pode usar em caso de falha.
- O AS50149 permanece registrado com uma associação Servercore/Selectel, mas atualmente não é anunciado nos dados de roteamento observados pelo RIPE, portanto, a continuidade deve ser testada em relação aos endpoints de serviço ativos, contratos, instalações, cópias e caminhos de recuperação, em vez do antigo rótulo de rede.
Um nome de região é apenas a primeira decisão
Imagine uma empresa de pagamentos abrindo um seletor de localização e escolhendo Moscou porque seus usuários estão na Rússia. O rótulo estabelece uma localidade geral, mas não responde às perguntas que importam durante uma falha. Qual empresa fatura o cliente? A máquina virtual está em um único rack, um único prédio ou em um pool distribuído entre vários prédios? O armazenamento segue o mesmo limite de falha que a computação? O tráfego pode sair por um operador independente? Se a conta ficar inacessível, o cliente pode recuperar uma cópia utilizável em outro lugar?
Oguia de localizações da Selectelatual fornece uma hierarquia inicial particularmente útil. Ele distingue países, regiões, zonas de disponibilidade, pools e segmentos de pool, e indica que a escolha afeta a disponibilidade, a tolerância a falhas e o balanceamento de carga. Essa hierarquia é importante porque os termos não são intercambiáveis. Uma região pode conter várias zonas de disponibilidade. Uma zona de disponibilidade pode conter um ou mais data centers. Um pool de zona única ainda pode ter segmentos em racks diferentes, mantendo a zona de disponibilidade como limite de falha comum. Um pool multizona pode colocar segmentos em vários data centers, mas isso não significa que cada produto, disco ou configuração do cliente cubra automaticamente esses segmentos.
Amatriz de disponibilidade atualtorna a distinção concreta. Ela lista São Petersburgo, Moscou, Novosibirsk, Tashkent, Almaty e Nairóbi, e mostra a disponibilidade de diferentes produtos e hardwares em pools individuais. A matriz é uma prova de que uma oferta estava publicamente disponível em um local indicado em uma determinada data. Não é uma prova de que dois locais exibidos têm fontes de alimentação independentes, operadores upstream independentes, pessoal independente, estoque de reposição igual ou um mecanismo de recuperação comum.
A camada comercial diverge ao mesmo tempo. Ostermos dos servidores dedicados da Selectelidentificam a JSC Selectel como fornecedora para as regiões russas e usam um tratamento separado para locais fora da Rússia. Ocontrato de uso da Servercoredetermina um contratante e a lei aplicável com base no país da conta. Um comprador não pode, portanto, registrar com segurança "Servercore/Selectel" como um único fornecedor indiferenciado. O contrato, o cronograma de serviço, o código de localização e a fatura devem ser registrados juntos.
Agora siga a escolha de Moscou mais adiante. Um código de pool aponta para recursos de computação e armazenamento. Esses recursos estão em racks conectados à distribuição elétrica, refrigeração e switches de acesso. Os racks estão em um grupo de data centers nomeado. O data center alcança outras instalações e a Internet por meio de links e roteadores de borda. A recuperação pode depender de uma segunda zona, um cluster de backup, uma cópia externa, DNS e credenciais que permanecem disponíveis quando o plano de controle principal não está. A afirmação de continuidade é tão forte quanto o elo não verificado mais fraco dessa cadeia.
Essa abordagem também altera as compras. O comprador não seleciona apenas a latência e o preço. Ele compra um conjunto de dependências físicas, de rede, de software, humanas e jurídicas. Uma região de baixa latência pode ser bastante adequada, mas o cliente deve decidir qual falha ela foi projetada para suportar. A proteção contra uma falha de host não é proteção contra um evento de energia de rack. A proteção de um único prédio não é necessariamente proteção contra um evento de fibra metropolitana. A replicação em um único provedor não é necessariamente portabilidade além desse provedor.
O nome da empresa se divide no contrato
O nome "Servercore JSC Selectel" é compreensível como uma associação histórica ou de recurso de rede, mas é perigoso como uma suposição contratual atual. Apágina de partes contratantesda Servercore lista a Servercore CIS, FE LLC para o Uzbequistão, MSS LLP Modern Server Solutions LLP para o Cazaquistão e Servercore Africa Ltd para o Quênia. Suapágina de informações jurídicasmais detalhada publica os endereços correspondentes, detalhes de registro, informações bancárias e condições específicas de cada país. Nenhuma das duas páginas apresenta a JSC Selectel como a contratante atual da Servercore para esses três países de conta.
O lado russo é mais claro nocontrato de uso da Selectelseparado, que identifica a JSC Selectel e seus detalhes russos. Isso não é uma diferença semântica. O contratante nomeado determina a lei aplicável, a moeda, a documentação fiscal, a via de pagamento, o processo de notificação e a entidade contra a qual uma obrigação de serviço pode ser executada. Ele também determina qual provedor tem a responsabilidade direta quando o serviço anunciado depende de uma instalação parceira ou da infraestrutura de outra empresa.
Apágina empresarialpública da Servercore agora apresenta sua proposta de infraestrutura local por meio de estudos de caso no Cazaquistão, Uzbequistão e Quênia. Essa orientação é consistente com sua lista atual de contratantes. Ao mesmo tempo, a documentação técnica compartilhada e a visibilidade do status continuam a expor os pools russos ao lado dos pools internacionais. O resultado é uma família de serviços comercialmente conectados cuja fronteira jurídica é mais nítida do que sua apresentação operacional sugere.
Essa distinção não deve ser superestimada no sentido oposto. Entidades jurídicas distintas não provam equipes de engenharia distintas, softwares distintos, compras distintas ou redes distintas. Tampouco a linguagem técnica compartilhada prova que uma entidade possui o prédio de outra entidade ou garante suas obrigações. Os documentos públicos estabelecem que o catálogo de serviços, a nomenclatura de pools e a visibilidade operacional estão vinculados. Eles não publicam um cronograma completo de responsabilidades interempresariais, um registro de ativos ou um acordo de inadimplência cruzada.
Para os clientes, a resposta prática é um registro contrato-recurso. Ele deve indicar o país da conta, o contratante, a região de serviço, a zona, o pool, o operador da instalação se divulgado, o local dos dados, a moeda de pagamento, o canal de suporte e o método de exportação. Se um revendedor, uma instalação parceira ou uma afiliada estiver envolvido, o cliente deve perguntar qual obrigação permanece com a parte contratante e qual é transmitida. A resposta deve cobrir créditos de serviço, acesso a dados, avisos de incidentes, assistência remota e ajuda na recuperação.
A distinção torna-se particularmente importante durante uma perturbação jurídica ou financeira, em vez de elétrica. Um servidor funcional pode se tornar operacionalmente bloqueado se um canal de pagamento falhar, se uma conta for suspensa, se um administrador da empresa sair ou se instruções transfronteiriças não puderem ser executadas. Inversamente, um contrato sólido não pode manter um rack refrigerado durante uma falha de serviços públicos. O planejamento de continuidade deve unir as duas camadas sem fingir que são a mesma camada.
A soberania dos dados merece a mesma precisão. Localizar uma carga de trabalho em um estado pode ajudar a cumprir os requisitos de localidade, e o contratante pode fornecer declarações de conformidade de suporte. No entanto, a localidade não responde por si mesma à pergunta de quem pode administrar o serviço, onde os metadados são processados, qual lei rege a conta ou se uma cópia utilizável pode ser movida para outra jurisdição. Um comprador deve mapear cada conjunto de dados regulamentado para o serviço e contrato reais, não apenas para a marca guarda-chuva.
O que a pegada russa realmente contém
A Rússia é a parte mais profundamente divulgada do catálogo combinado de infraestrutura. Apágina de data centersda Selectel indica que ela possui seis data centers Tier III em Moscou e São Petersburgo, com 3.612 racks e 30 MW de energia conectada. Ela identifica Tsvetochnaya 1 e 2 em São Petersburgo, três instalações Dubrovka na região de Leningrado e a instalação Berzarina em Moscou. A mesma página também identifica instalações parceiras, incluindo Aviamotornaya em Moscou e Svetlaya perto de Novosibirsk, em vez de tratar silenciosamente cada local como próprio.
Esses números são valiosos porque ancoram a nuvem em prédios. Eles mostram que a oferta russa não é um único salão anônimo. Os locais listados têm diferentes números de racks e números de energia conectada: a maior instalação divulgada, Berzarina, é listada com 1.420 racks e 10 MW, enquanto os prédios menores de Dubrovka têm pegadas sensivelmente diferentes. A separação física em São Petersburgo e na região de Leningrado cria opções que um cliente pode usar se o produto selecionado as suportar.
Mas "seis data centers" não é a mesma coisa que seis domínios de falha independentes para cada serviço. O guia de localizações agrupa Tsvetochnaya e Dubrovka em zonas de disponibilidade distintas de São Petersburgo. Em Moscou, ele agora lista Berzarina, Aviamotornaya, um grupo Moscou Norte e Ryabinovaya em quatro rótulos de zonas de disponibilidade. Novosibirsk é representado pela instalação Nextremum. Um produto pode estar ausente de uma zona listada, limitado a um pool ou disponível apenas mediante acordo prévio, conforme mostrado na matriz de disponibilidade.
Adescrição de colocationadiciona outro limite físico. Ela indica que o equipamento de colocation é colocado em um pool em data centers Tier III e que a Selectel fornece energia, conectividade, condições ambientais e segurança física. Ela também descreve a manutenção pelo cliente ou o serviço remoto pelos engenheiros da Selectel. Trata-se de um serviço de instalação direta, diferente de um cliente de nuvem cuja máquina virtual é colocada em hosts de propriedade do provedor e cuja localização no rack é abstrata.
Em março de 2026, a Selectel anunciou umanova região multizona de disponibilidade em Moscoubaseada em três zonas em data centers distantes até 15 quilômetros. O anúncio indica que os nós mestres do Kubernetes gerenciado, os nós de bancos de dados gerenciados e os backups distribuídos podem ser colocados em várias zonas. Isso é mais forte do que uma afirmação genérica de que "Moscou" é resiliente, pois descreve o número de zonas previsto, a escala de separação e os serviços que se beneficiam da distribuição automática.
É preciso ainda lê-lo como uma arquitetura específica de produto. Um projeto metropolitano pode reduzir a exposição a uma falha de prédio, a um incidente elétrico local ou a um evento de rack único. Ele não protege automaticamente contra um defeito propagado por um software compartilhado, uma ação de conta comum, um problema de conectividade metropolitana ou uma interrupção jurídica regional.
A afirmação do provedor de que os sites são conectados por uma rede comum de alta velocidade com baixa latência é útil para serviços síncronos, mas a conectividade comum também pode se tornar uma dependência compartilhada se o tráfego do cliente não tiver uma alternativa testada.
A descrição mais defensável da pegada russa é, portanto, em camadas. Existem prédios próprios e parceiros divulgados; zonas de disponibilidade e pools nomeados; funcionalidades multizona específicas de produtos; e serviços de rede e controle compartilhados. Há informações públicas suficientes para projetar uma separação significativa. Não há o suficiente para assumir uma separação simplesmente porque dois códigos de recurso aparecem sob uma mesma região.
Fora da Rússia, as instalações parceiras alteram a fronteira
Os locais internacionais tornam a fronteira do operador mais visível. O guia de localizações identifica duas zonas de disponibilidade em Tashkent na UNICON na rua Mingbulok e na East Telecom na rua Yangishakhar, uma zona em Almaty na Kazteleport Sairam e uma zona em Nairóbi na iColo NBO1. Essas são instalações parceiras nomeadas, não uma prova de que a Servercore ou a JSC Selectel possui o imóvel, a conexão elétrica ou cada camada das operações do site.
Apágina de infraestrutura de rededa Servercore divulga uma zona de disponibilidade em Almaty, duas em Tashkent e uma em Nairóbi, com diferentes certificações de instalação e descrições de confiabilidade. Ela também descreve um projeto de rede comum, vários provedores e conectividade regional. Lida em conjunto com o guia de localizações, a página apoia a existência de uma pegada de serviço internacional atual, preservando a distinção entre o provedor de serviços e o operador da instalação.
Oatestado PCI da Servercore para o Uzbequistãofornece uma forma mais restrita de corroboração para um perímetro de data center em Tashkent. Tal atestado pode apoiar uma avaliação de conformidade para o serviço e período nomeados. Ele não estabelece a propriedade, a potência de rack disponível, a ocupação atual, a diversidade de rotas ou a capacidade de recuperar na segunda zona de Tashkent. As evidências de certificação devem, portanto, permanecer vinculadas ao serviço e ao perímetro que realmente cobrem.
Apágina de status pública da Servercoreé particularmente reveladora. Em 18 de julho de 2026, ela exibia pools internacionais como uz-1a, uz-2a, kz-1a e ke-1a, pools russos como ru-1a a ru-9a, e categorias separadas para nuvem, bare metal, serviços de rede, data centers, energia, refrigeração, interfaces e faturamento. Ela também mostrava todos os sistemas operacionais no momento da observação, mantendo o histórico de incidentes. Isso apoia a visibilidade operacional atual em toda a plataforma. Não diz que todos os recursos compartilham um contratante, um proprietário de instalação ou uma garantia de recuperação.
A página de status é um indicador pontual, não uma auditoria de disponibilidade. Um ponto verde mostra o que o sistema de monitoramento do provedor sinaliza naquele momento. Ele não pode estabelecer a ausência de impacto parcial no cliente, a diversidade física de dois caminhos ou o sucesso de uma restauração individual. Seu histórico de incidentes é mais útil quando combinado com a própria telemetria do cliente, pois ambos podem revelar atrasos de detecção, diferenças de perímetro e falhas correlacionadas.
Os clientes internacionais enfrentam uma assimetria adicional. Tashkent tem duas zonas divulgadas, enquanto Almaty e Nairóbi têm uma cada no catálogo de localizações atual. Um país de zona única ainda pode ter energia, refrigeração e dispositivos de rede redundantes dentro de sua instalação, mas não oferece a mesma separação de prédio dentro do país. Um cliente que precisa de residência de dados no país e continuidade no nível do prédio pode precisar combinar os serviços do provedor com um segundo site independente, ou aceitar que a recuperação atravesse uma fronteira nacional.
Essa escolha tem consequências jurídicas e técnicas. O contratante segue o país da conta, e um alvo de recuperação transfronteiriço pode introduzir outro conjunto de requisitos de transferência de dados, fiscais e de pagamento. O projeto não pode ser feito por um engenheiro olhando apenas para a latência. O consultor jurídico não pode fazê-lo lendo apenas o contrato. Ambos precisam do mesmo mapa de dados, serviço, instalação e local de recuperação.
AS50149: registrado, mantido e atualmente silencioso
O AS50149 é o exemplo mais marcante de por que um rótulo de rede deve ser testado em vez de herdado. Avisão geral AS para AS50149do RIPEstat retornou o texto de titular "Servercore JSC Selectel" em 18 de julho de 2026 e marcou o sistema autônomo como não anunciado. Essa string de titular explica a associação de diretório. É uma prova de registro, não uma prova de transporte de pacotes atual ou de uma única entidade jurídica atual que carrega toda a frase.
Oregistro de status de roteamentodo RIPEstat é mais decisivo sobre a visibilidade atual. Ele não mostrou nenhum espaço IPv4 ou IPv6 anunciado, nenhum vizinho observado e zero peers RIPE RIS vendo o sistema autônomo. Ele relatou o último prefixo observado sob o AS50149 em 18 de abril de 2023. Aresposta de prefixos anunciadosseparada retornou uma lista de prefixos vazia para a janela de observação recente e observou explicitamente que as rotas com visibilidade muito baixa são excluídas.
Essa é uma forte evidência negativa para o AS50149 como uma origem de Internet atualmente visível. Não é uma prova de que nenhum dispositivo interno, interconexão privada, endereço de cliente ou configuração faz referência ao número. Os coletores de rotas públicos não veem todos os caminhos privados, e uma rede pode fornecer serviços por meio de outro sistema autônomo. O que a evidência exclui é a suposição fácil de que o AS50149 representa atualmente uma grande pegada de nuvem Servercore anunciada publicamente.
Aresposta WHOIS do RIPEadiciona um contexto importante. Ela lista o nome AS como Servercore, vincula o recurso a ORG-SL223-RIPE, mostra MNT-SELECTEL entre os mantenedores e registra uma modificação em abril de 2026. A manutenção do registro e o anúncio de rota são atos diferentes. O recurso pode permanecer atribuído e recentemente mantido mesmo quando não anuncia nenhuma rota visível pela rede de coletores.
Para comparação, avisão geral AS para AS49505do RIPEstat identificou "SELECTEL JSC Selectel" e marcou esse sistema autônomo como anunciado na mesma data. Isso não prova que cada serviço da Servercore ou Selectel passa pelo AS49505, nem divulga o caminho físico exato para um cliente. Isso mostra que a identidade de rede ativa da Selectel no roteamento público não é o AS50149.
A implicação operacional é simples. Um cliente deve identificar o sistema autônomo de origem real e o caminho upstream para cada endpoint de produção, não copiar o AS50149 de um perfil antigo. A Servercore fornece umLooking Glasspúblico para observações de latência e rota. Essas observações devem ser repetidas a partir das redes de usuários importantes do cliente e do local de recuperação proposto. Uma única medição não é suficiente: os caminhos podem mudar dependendo do destino, protocolo, tempo e política upstream.
Os números AS também dizem pouco sobre a independência das instalações. Duas zonas podem anunciar pelo mesmo sistema autônomo e usar links fisicamente diversos; dois sistemas autônomos podem ainda compartilhar um conduíte, um prédio ou um operador upstream. As evidências BGP estabelecem a identidade de roteamento e a acessibilidade, enquanto os documentos de instalação estabelecem locais nomeados. Apenas divulgações de rota, informações sobre operadores e medições repetidas podem começar a conectar os dois, e mesmo assim, um caminho de fibra exato não deve ser inferido de um mapa lógico.
O backbone é redundante apenas dentro de limites definidos
A Servercore descreve seis roteadores em cada região, uma carga de link alvo máxima de 50%, infraestrutura N+1 e vários fornecedores de equipamentos de rede. Sua página de rede nomeia Juniper, Arista, Huawei e H3C e descreve fabrics cloud leaf-spine, conexões redundantes e várias operadoras de telecomunicações na borda. Essas são escolhas de projeto sensatas. Múltiplos dispositivos podem absorver uma falha de componente, a margem de tráfego pode acomodar o re-roteamento, e a diversidade de fornecedores pode reduzir a dependência de uma única cadeia de suprimentos.
Essas são ainda afirmações do provedor sobre a arquitetura e os objetivos operacionais. "Seis roteadores" não identifica quais funções esses roteadores desempenham, quais domínios de falha eles ocupam ou se cada produto cliente passa por todos eles. "Carga de link máximo 50%" não publica o uso da série temporal, a distribuição do tráfego ou a condição após múltiplas falhas. O N+1 protege contra a perda definida de um componente necessário; não promete a sobrevivência de qualquer evento de modo comum.
Adescrição do Global Router da Selecteltraça uma fronteira de serviço valiosa. Ela indica que o serviço L3 privado pode conectar produtos e pools, usa equipamento reservado e roteamento dinâmico, e fornece largura de banda base de 25 Gbit/s em uma região e de 1 Gbit/s entre regiões. Diz também que o roteador não pode conectar produtos em diferentes países. Um cliente não pode tratar o catálogo comum de locais russos, uzbeques, cazaques e quenianos como uma única infraestrutura de recuperação roteada privada.
A conectividade transfronteiriça ou externa requer outro mecanismo. Adescrição do Global Connectindica que as conexões a plataformas de nuvem globais são arranjadas via Megaport, com uma VLAN dedicada e um link reservado pré-provisionado do lado da Selectel. Este pode ser um caminho híbrido útil, mas introduz dependências de parceiro e provisionamento. Uma conexão lógica dedicada também não prova por si só um caminho fisicamente disjunto do caminho comum da Internet do cliente.
Para o serviço de entrada, adescrição do balanceador de carga tolerante a falhasindica que o produto pode distribuir o tráfego da Internet entre serviços em diferentes regiões e zonas de disponibilidade, usando um endereço externo anunciado via BGP anycast. Ele depende do Global Router para alcançar a infraestrutura alvo. Essa combinação pode reduzir a dependência de um servidor ou zona, mas continua sendo uma cadeia: o anúncio externo, o serviço de balanceamento de carga, o roteamento privado e os alvos saudáveis devem funcionar todos.
O cliente deve, portanto, exigir respostas condicionadas por falhas. Qual largura de banda resta após a perda de um link ou roteador? Qual caminho transporta o tráfego de replicação se o caminho interzona normal falhar? O tráfego de controle compartilha a mesma borda? O suporte pode mudar um upstream durante um incidente, e como essa solicitação é autenticada? O ambiente de recuperação é acessível se a interface de conta principal estiver degradada? Essas respostas são mais úteis do que um rótulo "rede redundante" sem qualificação.
Há também uma dimensão econômica. Portas redundantes, operadoras e largura de banda reservada custam dinheiro mesmo quando ociosos. Um preço de computação anunciado baixo pode coexistir com taxas de saída, tráfego inter-região, conexões dedicadas ou largura de banda mais alta. Uma comparação de continuidade deve quantificar a operação normal, a replicação, os testes de restauração de rotina e pelo menos um intervalo de failover realista. Caso contrário, a "região de backup" pode ser projetada, mas não financiada para ser usada.
Os números de capacidade param antes da capacidade utilizável
A divulgação de 3.612 racks e 30 MW dos data centers russos é a evidência de capacidade pública mais sólida deste perfil, mas seu significado tem limites. A página descreve a energia conectada às instalações. A energia conectada não é a mesma que a carga de computação atualmente instalada, a energia vendida aos clientes, a energia disponível após as reservas de redundância ou a capacidade que um novo cliente pode contratar. O número de racks também não indica racks ocupados, densidade de potência, espaço não utilizado ou o número pronto para uma configuração de servidor específica.
Os números individuais das instalações são mais informativos do que o agregado, pois revelam a concentração. Duas instalações representam 20 MW dos 30 MW divulgados, enquanto os sites menores em São Petersburgo e na região de Leningrado variam de 2 MW a 3 MW. Um cliente distribuindo instâncias em dois códigos de pool deve determinar se esses pools ocupam realmente prédios e sistemas elétricos diferentes. O agregado não pode responder a essa pergunta.
A matriz de disponibilidade fornece um segundo tipo de sinal de capacidade: se os produtos e famílias de processadores específicas são exibidos como disponíveis, indisponíveis ou disponíveis por pré-encomenda em um pool. Isso está mais próximo de um inventário utilizável pelo cliente do que um número de megawatts de projeto. No entanto, continua sendo um catálogo datado, não uma reserva. "Disponível por pré-encomenda" pode implicar um prazo de fornecimento ou implantação, e uma marca de seleção não divulga a quantidade. O cliente precisa de um orçamento, um compromisso de entrega e uma política de substituição.
Atabela de preçospública da Servercore documenta os produtos e as taxas em seus mercados. O preço pode ajudar a estimar o custo dos recursos de recuperação reservados, mas não publica a computação instalada, hosts livres, margem de armazenamento ou inventário de emergência garantido. O acesso sob demanda é valioso para escalonamento normal; não é uma promessa de que o hardware idêntico estará disponível durante um pico de demanda em toda a região.
A demanda é visível indiretamente. A Selectel relatou umareceita de 2025 de 18,3 bilhões de rublos, com 87% provenientes de serviços de infraestrutura em nuvem e 32.900 clientes no final do ano. Esses números indicam uma atividade operacional substancial e crescente. Eles não podem determinar a margem de capacidade. O crescimento da receita pode apoiar o investimento, mas o crescimento do número de clientes e cargas de trabalho mais pesadas também podem consumir a nova capacidade.
As condições dos produtos expõem outra distinção útil. Adescrição do servidor em nuvemindica que os servidores virtuais são executados em recursos físicos da Selectel e distingue o serviço regular das instâncias preemptivas. Oguia de servidores preemptivosseparado indica que essas instâncias podem ser interrompidas a qualquer momento, inclusive quando o host fica sem recursos para outros servidores, e não recebem a garantia de disponibilidade normal da plataforma em nuvem. A capacidade não é, portanto, um pool indiferenciado: a computação interrompível barata e a computação de qualidade de continuidade têm usabilidade diferente em falhas.
Um levantamento de capacidade responsável deve parar no que é público. A Rússia divulgou a energia conectada e os totais de racks. As matrizes de produtos divulgam as ofertas específicas de localização. Os resultados financeiros demonstram a escala operacional. Nenhum documento público examinado estabelece a ocupação atual, a energia vendida, a capacidade do cliente reservada, o inventário agregado de CPU ou GPU, o uso de armazenamento, o tempo de funcionamento do gerador sob carga, a margem de refrigeração ou a capacidade de reserva após uma falha composta. Essas incógnitas pertencem às perguntas de compra, não a uma estimativa inventada.
A eletricidade, a refrigeração, o hardware e o pessoal são as verdadeiras dependências
Cada região de nuvem se resolve finalmente em eletricidade, remoção de calor, equipamento e pessoas. A página de data centers da Selectel descreve alimentação ininterrupta, refrigeração, segurança e monitoramento, enquanto a documentação de colocation atribui essas funções da instalação ao provedor. Esses controles reduzem o risco normal do site. Eles não eliminam as dependências de fontes de alimentação, quadros de distribuição, sistemas UPS, geradores, combustível, loops de refrigeração, controles de incêndio e pessoal autorizado a operá-los.
A questão de continuidade mais importante não é se a redundância existe, mas onde ela termina. Fontes de alimentação duplas em um servidor só ajudam se alcançarem caminhos de distribuição independentes. Um gerador só ajuda se a partida, a comutação, o combustível e a refrigeração permanecerem disponíveis durante a duração da falha. Duas instalações só ajudam se a carga de trabalho e seus dados ocuparem realmente ambas e nenhuma rede compartilhada ou ação de controle as desabilitar juntas. A hierarquia de localizações pública é uma base para fazer essas perguntas, não um substituto para as respostas.
O fornecimento de hardware é particularmente relevante através da fronteira entre a Servercore e a Selectel. O uso de várias marcas de equipamentos de rede pela Servercore pode reduzir a dependência de um único fabricante. Também pode exigir mais tipos de peças de reposição, trabalho de compatibilidade de software e habilidades especializadas. O hardware de computação apresenta uma compensação semelhante: um cliente pode ter acesso a processadores alternativos, mas uma substituição exata de bare metal ou GPU pode ter um prazo de fornecimento mais longo do que uma máquina virtual.
A divisão de responsabilidades entre o cliente e o provedor muda conforme o produto. Oguia de responsabilidadesatribui a infraestrutura física e grande parte da camada de virtualização de nuvem à Selectel, enquanto os clientes mantêm a responsabilidade pelos controles importantes do sistema operacional, aplicativos, identidades e dados, dependendo do serviço. Um prédio resiliente não pode consertar um aplicativo que tem um único líder de banco de dados, uma credencial expirada ou uma ação de administrador destrutiva replicada em todas as zonas.
As pessoas fazem a ponte entre essas camadas. O serviço de assistência remota pode substituir um componente para um cliente de colocation, enquanto os engenheiros do provedor mantêm os hosts de nuvem e os dispositivos de rede. Durante um incidente generalizado, o mesmo pessoal pode cuidar da energia, do hardware, da comunicação com o cliente e das prioridades de recuperação. Compradores com objetivos de recuperação rigorosos devem perguntar sobre a cobertura de escalonamento, contatos autorizados, estoque de reposição, acesso durante um fechamento de site e como os incidentes concorrentes são priorizados.
A jurisdição e o pagamento são dependências físicas de outra forma. Os contratantes específicos de cada país da Servercore usam bancos e moedas locais, o que pode tornar as operações locais normais mais fáceis. Mas uma empresa dependente de financiamento transfronteiriço ou aprovação central deve testar como as faturas são pagas durante uma perturbação bancária e qual aviso precede a suspensão. Osconselhos de segurança da informaçãoda Selectel orientam os clientes para os termos de serviço para destruição de dados após o término ou não pagamento dos serviços e indicam onde aparecem as notificações de manutenção e incidente. A continuidade financeira e a retenção de dados não podem ser deixadas a uma suposição de contas a pagar.
A colocação local dos dados também tem um custo de portabilidade. A descrição do servidor em nuvem indica que os servidores em nuvem russos estão em conformidade com a estrutura de dados pessoais russa declarada por padrão, enquanto a Servercore comercializa conformidade local em seus três países atuais. Isso pode satisfazer um requisito essencial, mas uma cópia de recuperação fora do país pode não ser permitida. Se a cópia precisar permanecer dentro de um país com uma zona divulgada única, a arquitetura precisa de uma opção independente dentro do país ou de uma aceitação explícita do risco residual da instalação.
A recuperação é um projeto de carga de trabalho, não um rótulo de produto
Os backups são o ponto onde a linguagem de continuidade encontra um objeto recuperável. Acomparação de métodos de backupda Selectel indica que os backups de servidores em nuvem não são feitos por padrão. Ela distingue backups programados ou manuais de volumes, imagens, snapshots, softwares de backup baseados em host e opções de cópia externa. Mais importante, ela diz que um snapshot permanece no mesmo hardware que o volume e é excluído com ele, portanto, um snapshot não é um backup completo.
O limite de armazenamento varia conforme o método. Oguia de backup de volume de redeindica que os backups completos e incrementais são armazenados em três cópias em equipamento dedicado. Em um pool de zona única, cada segmento tem um cluster isolado que armazena backups e discos; no pool multizona ru-6, um cluster de armazenamento compartilhado atende todos os segmentos do pool. Três cópias melhoram a resiliência de mídia e servidor, mas o número de cópias sozinho não estabelece a independência do prédio ou do provedor.
A portabilidade também varia. A comparação de métodos indica que os backups de volumes comuns não podem ser baixados, enquanto as imagens podem ser baixadas e movidas para uma infraestrutura de terceiros. Ela observa que as imagens são armazenadas separadamente dos volumes, mas no mesmo segmento de pool, a menos que o cliente as mova ou exporte. Um comprador cujo plano de saída depende de um backup deve verificar o formato, o tempo de exportação, as chaves de criptografia, a largura de banda e o procedimento de inicialização antes de escolher esse método.
O sucesso da criação não é o sucesso da recuperação. Oguia de criação de backupindica que os backups não têm verificação automática de integridade ou funcionalidade e recomenda restauração periódica. Essa recomendação deve se tornar um teste de recuperação observado: criar o novo volume, iniciar uma instância limpa, iniciar o aplicativo, validar a consistência dos dados, restaurar segredos por um caminho independente e medir o tempo decorrido.
O anúncio da região multizona de Moscou melhora as opções para alguns serviços gerenciados e backup distribuído, mas não remove as responsabilidades de aplicação. Um serviço de banco de dados pode distribuir seus próprios nós enquanto o cliente deixa um serviço de identidade, uma fila de mensagens ou uma dependência de objeto em uma única zona. Uma camada de controle Kubernetes pode abranger várias zonas enquanto sua entrada, registro ou banco de dados externo não. O mapa de recuperação deve incluir cada dependência crítica, não apenas o cluster de computação mais visível.
Para as maiores infraestruturas VMware, oguia de failover DRaaSdescreve o failover de máquinas protegidas para a nuvem Selectel e a organização subsequente do retorno ou replicação reversa. É um mecanismo de recuperação mais explícito do que uma cópia passiva. Ele ainda depende de replicação prévia, acesso às interfaces pertinentes, alterações de rede, ordenação de aplicativos e recursos suficientes no site de recuperação. O tempo de recuperação e o ponto de recuperação são propriedades da configuração testada, não do nome do produto.
O melhor projeto geralmente tem duas camadas. A primeira é uma recuperação rápida dentro do provedor, usando outro rack, zona ou região onde o serviço permite. A segunda é uma cópia mais lenta, mas mais independente, sob credenciais diferentes e, quando a lei permite, um operador ou jurisdição diferente. A primeira reduz o tempo de inatividade para falhas de hardware comuns. A segunda lida com comprometimento de conta, falhas do plano de controle, perturbações contratuais e eventos que se correlacionam dentro do provedor.
Cinco testes de falha para compradores
O primeiro teste é a perda de uma instalação. Selecione um recurso de produção e trace sua computação, dados primários, dados de backup e entrada de rede para zonas e instalações nomeadas. Em seguida, suponha que o prédio principal não tenha eletricidade ou refrigeração por um dia. Um projeto bem-sucedido tem computação saudável em outro lugar, uma cópia consistente, capacidade reservada suficiente, direcionamento de tráfego funcional e pessoal capaz de executar a mudança sem entrar no local com falha. Simplesmente ter outra zona no menu não é sucesso.
O segundo teste é um incidente de backbone ou plano de controle. Suponha que o tráfego do cliente não possa alcançar uma borda, ou que a interface de conta e o endpoint de programação estejam indisponíveis enquanto as máquinas existentes continuam funcionando. Observe a origem e o caminho reais de várias redes através do Looking Glass e medições independentes. Confirme se o DNS, anycast, roteamento privado e acesso ao suporte falham juntos. Pré-autorize uma mudança de tráfego que não dependa da interface degradada.
O terceiro teste é uma restrição de fornecimento de hardware. Suponha que um servidor importante, acelerador ou peça de rede falhe e uma substituição idêntica não esteja disponível. Pergunte qual substituto está estocado, se o software e as licenças permitem, como os dados se movem e qual desempenho é perdido. Para bare metal, registre o prazo de entrega e os compromissos de peças de reposição. Para nuvem, estabeleça se o pool de recuperação realmente oferece a CPU, memória, GPU e classe de armazenamento necessários, em vez de confiar no nome do produto no nível do país.
O quarto teste é uma perturbação da entidade jurídica ou do pagamento. Suponha que o circuito de pagamento normal, o administrador da empresa ou o contratante local esteja temporariamente indisponível. Confirme a parte contratante, os termos aplicáveis, o proprietário da conta, os contatos de emergência, o período de carência, as alternativas de fatura e a autoridade para exportar dados. Mantenha mais de um administrador treinado e garanta que as credenciais de recuperação não sejam armazenadas apenas na conta afetada.
O quinto teste é a portabilidade. Comece com a cópia que a equipe afirma poder deixar a plataforma. Exporte-a, verifique sua soma de verificação, restaure-a em um destino limpo, reconstrua a rede e as identidades e execute uma transação de negócios. Meça o custo, a largura de banda e o tempo decorrido. Se a cópia não puder ser baixada, documente a conversão ou exportação no nível do aplicativo necessária. Se os dados não puderem deixar a jurisdição, use um destino verdadeiramente independente dentro dela ou indique a limitação aceita.
Esses testes classificam os clientes por exposição. Uma única máquina virtual com um disco anexado em um pool depende do host, rack, zona, conta e provedor. Duas instâncias em racks diferentes melhoram a tolerância do host e do rack, mas podem manter dependências no nível da zona. Um serviço multizona distribuído corretamente pode sobreviver a mais falhas físicas, mas ainda pode compartilhar a rede metropolitana, o software e o risco da contratante. Uma cópia externa adiciona independência, mas apenas se as credenciais, chaves, capacidade e autorização legal sobreviverem.
Os testes também facilitam a interpretação das garantias de serviço. Um crédito após uma parada ajuda no preço, não na recuperação. Uma porcentagem de alta disponibilidade diz pouco sobre uma rara falha longa se as condições excluídas, o método de medição e as obrigações do cliente forem desconhecidas. Os compradores devem usar a garantia para entender os incentivos e, em seguida, usar exercícios e telemetria para entender a capacidade de sobrevivência.
O veredito sobre a continuidade
A Servercore e a Selectel expõem informações atuais suficientes para apoiar um planejamento sério de infraestrutura. Os documentos públicos identificam as instalações russas e internacionais, nomeiam zonas de disponibilidade e pools, divulgam uma pegada significativa de racks e energia na Rússia, descrevem a redundância de rede, publicam matrizes de disponibilidade de produtos e mantêm uma página de status granular. As páginas jurídicas também tornam visíveis as entidades contratantes locais, em vez de apresentar uma contraparte universal.
As evidências não apoiam a redução de tudo isso a "Servercore JSC Selectel" como um único fato operacional atual. O AS50149 mantém esse texto de titular no RIPEstat, mas atualmente não é anunciado e não tem prefixos recentemente observados na visão dos coletores. A JSC Selectel é a contratante russa documentada e tem uma identidade de rede anunciada separadamente. O perímetro jurídico atual da Servercore nomeia contratantes do Cazaquistão, Uzbequistão e Quênia. Os data centers parceiros adicionam outra camada de operadora fora da pegada russa mais profunda.
A proposta de continuidade mais forte é, portanto, condicional. Na Rússia, um cliente pode escolher entre vários locais divulgados e, para os serviços suportados, um projeto multizona em Moscou. Em Tashkent, duas zonas nomeadas criam uma opção de separação dentro do país. Almaty e Nairóbi atualmente apresentam cada uma uma única zona de disponibilidade divulgada, portanto, a recuperação no nível do prédio requer uma resposta adicional. Entre países, o Global Router privado não fornece uma rede de recuperação transparente.
As evidências de capacidade também são condicionais. Trinta megawatts conectados e 3.612 racks demonstram uma escala física nas seis instalações russas divulgadas. Eles não revelam a margem utilizável em caso de falha. As matrizes de produtos e os rótulos de pré-encomenda ajudam, mas a capacidade de recuperação firme vem da reserva, do contrato e do exercício. A mesma disciplina se aplica à rede: N+1, múltiplos provedores e margem de tráfego são afirmações de projeto críveis, enquanto a independência atual de caminhos requer medições e divulgações.
Para um comprador, o documento decisivo não é uma lista de regiões. É um mapa de dependências que vincula cada serviço de produção à sua contratante, instalação ou zona, pool, cópia de dados, caminho de rede, canal de suporte e alvo de recuperação. O evento decisivo não é uma demonstração comercial. É uma restauração ou failover realizado sob uma suposição de perda realista.
Isso produz uma conclusão justa. A plataforma está visivelmente operacional mesmo que o AS50149 esteja silencioso. Sua continuidade pode ser forte quando o cliente usa deliberadamente domínios de falha separados, mantém uma cópia portátil e resolve antecipadamente as fronteiras jurídicas e de parceiros. Ela é fraca quando uma interface compartilhada, um ponto verde de status ou um antigo rótulo de sistema autônomo é tratado como prova de que essas fronteiras não existem.

