Como a Railway construiu seu próprio data center
(blog.railway.com)- A Railway concluiu que a computação baseada no GCP limitava preço, suporte e desenvolvimento de recursos, e iniciou o Railway Metal, uma infraestrutura física que poderia controlar de forma mais direta
- Após o início em janeiro de 2024, levou 5 meses até conectar o primeiro servidor e mais 3 meses até colocar workloads de usuários; 9 meses depois, o primeiro site na Califórnia entrou em operação
- A restrição maior não era o aluguel de espaço, mas energia e refrigeração; a Railway escolheu Cage Colocation em vez de Greenfield ou aluguel por rack
- A rede foi projetada para resistir à falha de um único data center, com pelo menos 2 ISPs por região, tabela completa de roteamento da internet, seleção de rotas por prefixo IP e múltiplas zones
- Foi necessário lidar diretamente com disposição dos racks, documentação de cabos, PDUs, switches com reverse airflow, Redfish API, PXE, FRR e SONiC; construir uma nuvem própria se parece mais com construir uma casa do que com fazer deploy via Terraform
Por que migraram do GCP para o Railway Metal
- Desde o início, a computação da Railway foi construída sobre o Google Cloud Platform
- O GCP ajudou no crescimento inicial, mas, à medida que a operação cresceu, surgiram limitações para oferecer aos clientes a plataforma desejada
- Operar sobre um hyperscaler limitava diretamente o preço, o nível de serviço e o escopo de desenvolvimento de recursos que a Railway podia oferecer
- taxas de egress afetam o preço
- quando há problemas na infraestrutura de base, raramente se entende a causa
- mesmo gastando milhões de dólares por ano, o nível de suporte foi avaliado como não muito diferente do de quem gasta 100 dólares
- Em resposta, a Railway iniciou em 2024 o projeto Railway Metal
- 9 meses depois, colocou no ar o primeiro site na Califórnia
- conduziu diretamente o projeto, a definição de especificações e a instalação, desde cabos de fibra óptica dentro do cage até contratos com ISPs
- está ativando mais 3 regions de data center
Primeira escolha de espaço: cage em data center
- O projeto Railway Metal começou em janeiro de 2024 e levou 5 meses até a conexão do primeiro servidor
- Foram necessários mais 3 meses até concluir que workloads de usuários poderiam rodar no hardware
- Uma infraestrutura própria precisa de espaço para os servidores, energia estável e refrigeração suficiente
- As opções eram, em linhas gerais, três
- Greenfield buildout: comprar ou alugar um data center
- Cage Colocation: obter uma área dedicada cercada por paredes de tela dentro de um data center de um operador
- Rack colocation: alugar racks individuais ou partes de racks em um data center de colocation
- A Railway escolheu Cage Colocation para ter quatro paredes, uma porta de segurança e um espaço vazio no qual pudesse projetar o restante por conta própria
- O custo do espaço em si não é alto, mas o custo de energia e da refrigeração associada é o maior
- há grandes diferenças de custo por kW dependendo da região
- no oeste dos EUA, pode-se pagar menos da metade do que em Singapura
- a energia é paga como um commit mensal para garantir disponibilidade sob demanda, independentemente do uso real
Projeto elétrico e PDU
- Para igualar a capacidade usada no GCP, a Railway definiu primeiro a meta de número de vCPUs, GB de RAM e TB de NVMe
- Com base nesses números, escolheu servidores e CPUs
- A variável central foi a densidade de energia, ou seja, colocar a densidade de computação desejada dentro de um consumo elétrico específico
- O cálculo elétrico não termina em somar watts e é mais complexo, especialmente com energia trifásica
- a Cloudflare aborda o tema em introdução à energia trifásica e PDUs
- Em um data center, energia é o recurso mais importante, e uma queda de energia pode ter um tempo de recuperação muito longo
- Cada rack precisa de 2 feeds de energia totalmente independentes
- em operação normal, os dois feeds dividem a carga
- o sistema precisa suportar a queda de um dos feeds
- Para entregar energia aos servidores, é preciso uma Power Distribution Unit
- uma PDU básica é, na prática, parecida com uma régua de tomadas expandida
- as PDUs implantadas pela Railway permitem controle e medição por tomada individual
- cada PDU é acessível pela rede, e tomadas individuais podem ser medidas e controladas remotamente
Rede: ISP, roteamento e caminhos por região
- Máquinas em cloud não existem isoladamente, por isso a rede tem papel central
- A Railway buscou instalações de data center com conexões robustas ao mundo externo para garantir baixa latência
- As condições preferidas eram as seguintes
- estar on-network com ISPs Tier 1
- estar presente em Internet Exchanges
- ter fibra óptica para conexão com outros data centers próximos
- Aplicações implantadas na Railway se comunicam com diversos endpoints
- um usuário de internet residencial em Sydney
- uma API hospedada em um servidor da AWS nos EUA
- Para baixa latência e baixo custo de banda, a Railway contratou vários provedores de internet otimizados para cada caso de uso
- Os ISPs foram escolhidos com base na maturidade de rede nas regiões-alvo
- trabalhar com o ISP errado pode criar hops de rede adicionais até um mercado-alvo específico, aumentando a latência
- no pior caso, podem surgir rotas de rede complexas e tortuosas
- em cada região, foram escolhidas pelo menos 2 redes separadas com base no footprint regional
- Depois da conexão, a Railway recebe de cada ISP a tabela completa de roteamento da internet e a consolida nos switches de rede para decidir a melhor rota por prefixo IP
- se um usuário na Austrália acessa um app implantado em Singapura, é provável que os pacotes sejam encaminhados pela Telstra
- se o mesmo app envia pacotes para um usuário ou servidor no Japão, é provável que sejam encaminhados pela PCCW
- Informações de peering são públicas, e é possível ver interconexões de rede em bgp.tools
- Para redundância, foram construídas várias zones dentro de cada region, e a interconexão entre sites também é importante para escalar
- foram consideradas ferramentas como dark fiber e wavelength service
- a direção é fazer com que o app não perceba diferença se o banco de dados estiver na mesma sala ou em um prédio vizinho a quatro quarteirões
- é um projeto para aumentar a resiliência a falhas de data centers individuais
Racks, corredores, refrigeração e rotas de cabos
- Em data centers, racks são organizados em fileiras, e os corredores entre eles são usados para fluxo de ar
- No Cold Aisle, o ar frio da instalação entra; os servidores puxam esse ar e o expelem pela parte traseira para o Hot Aisle
- Para aumentar a eficiência, o ar do Cold Aisle e do Hot Aisle não deve se misturar
- Mesmo usando equipamentos de 19 polegadas de largura, é possível escolher altura, largura e profundidade dos racks de acordo com as necessidades dos equipamentos e cabos
- A maioria dos equipamentos de servidor pode ser puxada para frente sobre trilhos para manutenção, então as dimensões do cage precisam permitir isso
- Cabos e gerenciamento de cabos também exigem espaço, criando um trade-off entre quão densamente preencher os racks e quantos racks colocar dentro do cage
- Na experiência da Railway, energia e refrigeração se tornam restrições com mais frequência do que o espaço físico em si
- Em novos sites, foram escolhidos racks mais largos, de 800 mm, para tirar os cabos do caminho de exaustão e melhorar o airflow
- Além dos racks, é necessária infraestrutura superior e bandejas para transportar energia e dados
- rotear fibras ópticas da borda do cage até cada rack
- rotear cabos entre racks
- esses itens às vezes são incluídos pelo operador do data center na cotação do cage
- Como a Railway tem alta densidade de cabos de fibra óptica switch-to-server por rack, comprou switches com reverse airflow, com as portas voltadas para a parte traseira do rack
- são switches que expelem ar pelo lado onde ficam as portas de rede
- as bandejas de cabos são alinhadas para que todo o cabeamento seja feito por um lado do rack
- isso evita que cabos fiquem ziguezagueando entre a frente e a traseira do rack
Documentação de instalação e rack-and-stack
- A Railway inicialmente tentou fazer o cabeamento por conta própria, mas os resultados foram inconsistentes, então trouxe especialistas para instalar corretamente
- É necessário um pacote de documentação abrangente para que os especialistas de instalação saibam o que deve ser instalado e onde
- Há dois tipos comuns de documentação
- Cabling matrix: define a localização dos equipamentos nas duas pontas de cada cabo, portas, especificações do cabo, tipo de fibra óptica, comprimento etc.
- Rack elevation: mostra visualmente a posição e orientação de cada equipamento dentro do rack
- Cada etapa de instalação da Railway inclui mais de 60 equipamentos, mais de 300 cabos individuais e dezenas de detalhes
- As especificações escritas e planilhas que servem de base para instalação e comissionamento foram criadas manualmente
- Após a chegada dos materiais ao local, concluir toda a instalação leva cerca de 6 a 14 dias
- Depois disso, a Railway criou uma ferramenta interna para automatizar a geração de build specifications
- Construir um cage de data center está distante de deploys comuns de software, DevOps e stacks Terraform; é mais parecido com construir uma casa
- Instalações de data center, contratadas e fornecedores variam um pouco na forma de trabalhar, mesmo dentro da mesma organização, exigindo atenção operacional muito detalhada
Exceções e problemas físicos encontrados em campo
- Em um site, as PDUs estavam instaladas de cabeça para baixo e, como a energia entrava pelo piso, a numeração planejada das tomadas ficou invertida
- No site de Amsterdam, havia um método de instalação em que o link externo de fibra óptica entrava diretamente em uma caixa dentro do rack, em vez de passar por um demarcation point dedicado
- Em uma instalação, diferente de outros sites, as tomadas de energia estavam cabeadas em phase-to-neutral; em outras, eram phase-to-phase
- Houve um caso em que a contratada não percebeu que o equipamento de rede era reverse airflow e tentou montá-lo na direção oposta, concluindo que os cabos de dados eram curtos demais
- A causa de um link que não subia em um cabo específico era erro de polarity da fibra óptica, e foi nessa ocasião que a Railway conheceu “rolling fibre cables”
- é o método de remover os plugs de um LC connector e trocá-los entre si
- Cerca de 24 PDUs de um fornecedor tinham defeitos nas tomadas, impedindo que os plugs de energia encaixassem corretamente, e nem aplicar força física resolveu
Trabalho de software após a instalação física
- Depois que o hardware está no lugar, o trabalho passa para uma área de software mais familiar
- As tarefas necessárias incluem
- configuração de BGP
- instalação de OS
- configuração de monitoramento
- configuração de equipamentos de rede
- escrita de configurações de roteadores
- atualização de registros no RIR, ou Regional Internet Registry
- Para acessar os controladores dedicados de servidores e PDUs, são usadas Redfish APIs
- Para inicializar servidores pela rede, é usado PXE
- O projeto de rede da Railway usa whitebox network switches rodando FRR e SONiC
- Com esse projeto, foi construída uma rede L3-only orientada por software, profundamente integrada ao control plane da Railway
- Nos últimos meses, a Railway criou novas ferramentas de software, Railyard e MetalCP
- projeto de novos cages
- rastreamento e visualização de cabos
- instalação de OS em servidores
- ferramentas que possibilitam uma experiência de clique em botão até o processo de conectar servidores à internet
- Um texto posterior abordará o processo de transformar um conjunto de servidores em uma sala em uma Railway zone funcional
1 comentários
Opiniões no Hacker News
Pela minha experiência e por textos como este, parece que o Google odeia ter clientes
Alguém decidiu que “precisamos ter uma nuvem pública” e eles a criaram, mas a sensação é que gostariam de manter os clientes afastados com uma vara de 3 metros
Tenho 100% de certeza de que um gerente de conta da AWS é o tipo de pessoa que, se preciso, rolaria com você na lama. Em uma crise, se você pedir, ele dormiria no chão junto com você
Já quando olho para os responsáveis do Google Cloud, fico triste. Porque dá para ver que eles são menos amados e menos apoiados dentro do Google do que nós. É lamentável ver alguém tentando convencer a própria empresa a vender e prestar serviço direito, e parece que eles foram colocados para fracassar
O pessoal da Microsoft é blindado: vende bem, presta bem o serviço e consegue arrancar todo o dinheiro do meu bolso enquanto me faz acreditar, até a morte, que isso é bom para mim. Só que a nuvem deles é uma coisa… muito estranha
A Railway ir para bare metal é algo ao qual, depois de uns 15 anos nisso, eu jamais, jamais, jamais gostaria de voltar. Não vale a pena. Mas acho que é preciso passar por isso para entender, e o caminho é assim mesmo
Logo eles vão descobrir por que exatamente o Google sofre tanto. Só que, se realmente tiverem uma vontade forte de vender serviços para pessoas, em vez de criar o Borg ou um cérebro artificial, podem fazer isso 100 vezes melhor que o Google
Mesmo assim, não acho que ele rolaria comigo na lama, o que é meio surpreendente. Fico curioso para saber quanto é preciso gastar para entrar no nível de acompanhamento na lama
Todo o serviço de nuvem parece ter sido projetado por alguém que não entende nada de cloud computing e só conhece “aluguel de servidores bare metal”. É cloud computing, mas de um jeito que destrói o próprio conceito de cloud computing
A ferramenta de linha de comando do GCP,
gcloud, também parece mais bem projetadaIsso teria nos poupado meses de trabalho preparatório
Pela minha experiência pessoal, o suporte do Google Cloud nos tratou muito bem mesmo quando éramos uma equipe pequena de 3 pessoas gastando muito pouco; em outra empresa, a Microsoft também nos tratou muito bem. Só que, naquela época, o volume de gasto provavelmente era alto o bastante para ser rastreável até pelo monitoramento da rede elétrica do data center
Já a AWS mentiu sobre um recurso e, no fim, nem respondeu
Os gerentes de conta que conversam com a alta liderança sobre contratos obrigatórios de milhões de dólares com a AWS parecem saber muito bem como falar com essa liderança
Mas, na etapa de realmente desenvolver e entregar produtos para outras pessoas, fomos deixados sozinhos na poeira
O mais engraçado é que o recurso sobre o qual mentiram tinha sido vendido como essencial para tornar a experiência do usuário final excepcional
Respondi ao ticket de suporte, mas não houve retorno; enviei e-mails para dois representantes da AWS e também não obtive resposta
Lembro dos velhos tempos da Rackspace. Foram muitos episódios que pareciam uma guerra de verdade.
O pessoal da EMC veio instalar equipamentos de storage para teste, tropeçou um no outro e derrubou um rack de servidores inteiro, como numa comédia. Naturalmente, não fecharam o contrato.
Um motorista de caminhão teve um ataque cardíaco e, por causa do acidente, o data center DFW ficou offline. Havia balizadores para evitar esse tipo de situação, mas eles ainda não tinham sido preenchidos com cimento.
Certa vez, improvisamos uma conexão disparando largura de banda por laser até outro prédio do outro lado da rua.
Em outro dia, um servidor literalmente começou a pegar fogo, então quebramos a janela e fomos comprar ventiladores de caixa.
A engenharia de data centers avançou bastante desde aqueles primeiros tempos. Na época, fizemos o OpenCompute Project com o Facebook, e havia conceitos de infraestrutura muito à frente para aquele período.
O principal link de micro-ondas continuava caindo com erros intermitentes de pacote em alguma camada bem profunda do enlace de dados. Investigando, descobrimos que uma árvore do outro lado da estrada estava ganhando folhas, e os galhos balançavam para dentro da linha de visada do equipamento no nosso prédio. Uma escada, uma serra e 10 minutos restauraram a conexão.
O roteador BGP principal de saída do data center vivia reiniciando. Não havia equipamento redundante. Ao verificar, a temperatura do data center estava alta demais e a refrigeração era tão ruim que o ar no lado dos ventiladores de entrada passava de 60 °C. Improvisamos apontando um ventilador para ele.
Algumas semanas depois, o ar-condicionado de outra sala também morreu e começou a jogar água em cima de um Nortel DMS-100. Era um ISP discado com seu próprio switch. Eu não queria ajudar a limpar aquilo porque pensei que poderia haver corrente elétrica na água, mas não tive escolha.
Depois disso, também trabalhei em uma pequena ilha remota, onde o link principal de internet era de 1 MB/s via satélite GS e o ping passava de 500 ms. Os moradores faziam dial-up por uma rede telefônica de micro-ondas classificada para 9600 baud, mas, de algum modo, modems de 56k funcionavam.
Um dia descobri que faltava uma
.soimportante em uma máquina Solaris, e não havia backup local nem mídia de instalação. Liguei para um amigo no Reino Unido e pedi que subisse uma cópia em um servidor FTP, e assim consegui colocar a máquina online de novo.Alguns anos depois, também instalamos um link a laser sobre a Oxford Road, em Manchester, então a rota de ônibus mais movimentada da Europa, para conectar o escritório ao campus da universidade. Eram tempos divertidos.
Foi tudo extremamente divertido, mas hoje sou muito grato por trabalhar quase só com software.
Mesmo que os servidores não tenham literalmente pegado fogo, abrir janelas e usar ventiladores aconteceu também em janeiro de 2024 no data center Equinix CH1, em Chicago. O Azure ExpressRoute caiu.
Ouvi dizer que ficou frio demais e os CRACs não aguentaram. Parece que deixaram todas as portas e janelas abertas para tentar manter frio o suficiente, mas no fim falhou. Quando o CRAC cai, os servidores vão junto.
Aquele switch com certeza era amaldiçoado. Mais tarde naquela semana, o mesmo equipamento teve um erro de configuração de spanning tree que paralisou a LINX por algumas horas, e metade do peering dos ISPs do Reino Unido entrou em caos temporário. Todas as outras pessoas envolvidas naquele projeto também morreram dentro de 2 anos.
Alguns anos depois, visitei as instalações e a carcaça assada ainda estava no chão embaixo dele.
A parte do texto que diz que “mesmo gastando milhões de dólares por ano, você só recebe o mesmo suporte de quem gasta 100 dólares” dói. Isso é um problema bem grande no Google.
Achei este texto especialmente interessante porque passamos por aventuras parecidas ao montar a infraestrutura da Blekko.
Para empresas como a Blekko, em que o tráfego entre racks — ou seja, o tráfego leste-oeste — é maior do que o tráfego de ida e volta para a internet, era essencial que serviços fisicamente co-localizados não competissem por largura de banda com outros servidores, e isso era muito mais econômico do que pagar por esse caso especial na SoftLayer, ou seja, na nuvem subordinada da IBM.
Existem empresas bem legais que constroem enclausuramentos para corredores frios. Basicamente, elas fazem com que todo o ar frio vindo do piso entre pela traseira dos servidores e não escape para outros lugares. Também impedem que ar menos frio das laterais seja sugado para dentro dos servidores.
O cálculo da capacidade de HVAC/CRAC em data centers também é interessante. Na nossa primeira instalação de colocation, tínhamos direito de preferência para expandir para a área de piso ao lado da nossa cage, mas, quando chegou a hora de expandir de fato, a instalação já não tinha capacidade de refrigeração restante, então isso não serviu para nada.
Depois de passar por esse tipo de processo, dá para entender muito melhor a solução da 0xide.
É assim que se constrói uma empresa dominante. Foi bom ignorar a sabedoria convencional chorosa que prende todo mundo aos hyperscalers.
Se você é uma empresa de infraestrutura, precisa possuir diretamente o bare metal que vende. Caso contrário, é apenas um intermediário de cloud e pode ser atropelado em preço a qualquer momento por concorrentes de bare metal com custo de egress de US$ 0.
Como é possível zerar o custo de egress com colocation e peering, a Cloudflare consegue oferecer um plano gratuito, e um novo entrante que revenda serviços de cloud não consegue competir com a Cloudflare.
Na verdade, para os hyperscalers, a cobrança abusiva por largura de banda não é apenas uma fonte de receita, mas um fosso defensivo. Ela impede que alguém construa a próxima AWS em cima da AWS e cria, sobre IaaS, um segmento de mercado completamente novo e estrategicamente mais fraco chamado “PaaS”.
Com isto, podemos cortar esse custo pela metade, reduzir também os custos de storage e eliminar a precificação “por assento”.
Estou realmente animado.
É um texto bem bom. Uma coisa que me vem à cabeça é: por que eles criaram uma ferramenta interna para gerenciamento de racks? O NetBox já existe
O NetBox é excelente, e eu teria adorado ter isso em meados dos anos 2000, quando gerenciava mais de 50 racks
https://github.com/netbox-community/netbox
Mas a ferramenta que criamos, o Railyard, se encaixa bem porque está profundamente integrada a todo o nosso stack de software, hardware e orquestração
O problema das ferramentas open source é que elas são genéricas demais. Em vez de resolver o problema, você acaba entortando o problema para caber no modelo de dados da ferramenta
No fim, é bem provável que integremos essa ferramenta ao próprio Railway. Se você quiser ir para on-premises, seria algo como oferecer design de hardware, comissionamento, implantação e experiência de desenvolvedor com um clique. Parecido com o que a Oxide faz, mas vindo pelo lado oposto
https://github.com/netbox-community/netbox/issues?q=is%3Aiss...
O NetBox quer ser a “fonte da verdade” da infraestrutura de rede
O que é importante varia conforme a situação, mas a história poderia ter sido diferente se o NetBox tivesse mirado em ser um repositório central, sem insistir que certos itens não podem ter outro sistema como fonte da verdade
Aprendemos que tentativas de centralizar complexidade e controle não funcionam. Isso já ficou claro quase imediatamente depois da aprovação do Clinger-Cohen Act, e agora ITIL e TOGAF também tratam disso explicitamente. Acho que consultores vão explorar bastante esse ponto nos próximos anos
É preciso haver uma forma central e consistente de encontrar o estado. Isso elimina a dúvida sobre onde encontrar a informação autoritativa
Mas, para escalar, crescer ou se adaptar a novas mudanças, é preciso evitar esses sistemas normativos do tipo caixa divina centralizada
Não é um software muito gratificante de usar
É o caso comum de “precisamos de X e Y faz X”, ignorando o fato de que Y também faz Z, M, Q e ainda lava a louça, e que você não precisa disso
Às vezes, a solução mais fácil é construir só o que você precisa. Especialmente quando o que você precisa é CRUD na frente de um banco de dados
Na prática, é só ampliar o escopo. O NetBox é um bom ponto de partida se você começar por ele e estiver disposto a moldar o sistema ao redor dele
Mas, se você já tem um sistema ou precisa fazer coisas que não se encaixam na lógica do NetBox, provavelmente é melhor simplesmente estender o sistema existente
Nesse caso, a Railway precisa cuidar de muito mais informações adicionais além de racks, endereços IP e servidores físicos
Já trabalhei com automação de reparo de equipamentos em uma grande empresa de tecnologia. Acho que reparo é subestimado, mas é uma das coisas mais difíceis de lidar
Quando você roda na AWS, quase não se preocupa com hardware defeituoso. Em geral, ele é consertado sozinho
Operando por conta própria, você não tem esse luxo. Precisa de peças sobressalentes, técnicos para fazer reparos, processos para tirar e recolocar trabalho nos hosts, suítes de teste, ferramentas de monitoramento de hardware e mais outras 1001 coisas
Em pequena escala, dá para empurrar parte disso com a barriga, mas uma hora a conta chega. E isso é só falando de servidores
Equipamentos de rede trazem outro conjunto divertido de problemas e, quando falham, podem derrubar um rack inteiro. Quanto você confia que o provedor de colocation não vai perder energia durante o pico de carga? Espero que façam simulados de recuperação de desastre para esses cenários
Boa sorte para essa equipe. Parece divertido
Isso me lembra alguns períodos da minha carreira. Entre 2003 e 2010, precisei implantar dezenas de milhares de servidores e aprendi coisas bem interessantes sobre datacenters
Gerenciamento e padronização de cabos eram extremamente importantes. Não dava para sobreviver com práticas bagunçadas
Onde implantávamos centenas de servidores por semana, quando um servidor era diferente de um dos clusters principais, havia um menu de opções que o operador podia escolher. Basicamente, havia 2 tipos de chassi: um servidor 2U com muitos discos ou uma caixa “pizza box” 1U. Os discos podiam ser SCSI de 9/36/146 GB
Todos eram dual-processor com o mesmo processador, e a parte de baixo do rack ficava com umas 10 caixas 2U; o restante era preenchido com mais de 20 caixas 1U
Se minha memória não falha, conseguíamos um preço de energia muito bom, provavelmente porque usávamos os racks da instalação dentro da cage. Acho que, usando esses racks, eles forneciam de graça os dois primeiros circuitos de 30 A a 240 V
Era um contrato de 10 anos e não havia medição, então enchíamos cada rack o máximo possível. De um lado colocávamos dois de 30 A; do outro, dois de 20 A
Considerando o calor que emitíamos e o consumo de energia, acho que o datacenter praticamente ficava no ponto de equilíbrio. Talvez compensassem com custos de conectividade ou peering
Não lembro bem dos detalhes, então preciso confirmar com um amigo que trabalhou lá naquela época
Há lugares em que faz sentido estar na nuvem, e outros em que não. Os melhores exemplos são aplicações de alta largura de banda ou com uso intensivo de disco
Olhando para a Netflix, quase tudo está na nuvem, mas a entrega real de vídeo é feita em hardware próprio. Mesmo na escala da Netflix, fico em dúvida se seria economicamente viável pagar alguém por isso
Ajustando um pouco um número que vejo com frequência: 20 PB de saída a US$ 0,02 por GB dá US$ 400 mil por mês
20 PB correspondem a aproximadamente 67 Gbps no percentil 95
Não é difícil encontrar um link flat de 100 Gbps por US$ 5 mil por mês
Claro, essa conta é simplificada demais e, na prática, entram muito mais fatores. Ainda assim, a diferença é grande
Para algumas empresas, US$ 4,68 milhões por ano pode não ser nada de mais; para outras, pode ser uma quantia de sobrevivência
Eu gostaria que houvesse muito mais detalhes. A seção WTF foi a melhor
Parece que os equipamentos precisam de placas do tipo “aponte este lado para o inimigo” ou de affordances adequadas para que só encaixem em uma direção
Vocês padronizaram o layout no nível do rack? Que procedimentos poka-yoke foram colocados para evitar erros?
Como é a stack do bare metal até o boot?
Como alguém que trabalhou em dois provedores de nuvem diferentes e montou uma nuvem interna diretamente com hosts de boot PXE, esse tipo de conteúdo é realmente fascinante
Ao iniciar um novo datacenter, é bom aproveitar ao máximo para testar todos os cenários de falha que vierem à mente, além de cenários que você nem imaginou por meio de injeção aleatória de falhas
Agora estamos padronizando o layout no nível do rack. Só percebemos isso depois do segundo site. Isso tornou a validação muito mais fácil
A validação é difícil e, até agora, estamos fazendo manualmente. Eu gostaria de tentar extrair os dados LLDP, mas há um bug na stack de software dos switches
É um processo em evolução constante. Quanto mais trabalhamos com diferentes empreiteiros, mais casos excepcionais descobrimos e incorporamos
A maior melhoria foi criar um DCIM interno para transformar o design dos racks em templates e exportar para os técnicos em campo um “explorador de cabeamento” interativo. Ele também inclui diagramas detalhados e anotados dos equipamentos, com nomes de portas etc. A captura de tela da elevação do rack mostrada no texto faz parte dessa ferramenta
Do bare metal até o boot, temos algo hackeado em cima de https://github.com/danderson/netboot/tree/main/pixiecore. Ele fornece o netboot do Debian e arquivos preseed
Também temos um worker Temporal customizado que se conecta à API Redfish do BMC para controlar esse dispositivo. Depois, um agente de host customizado provisiona VMs QEMU, e no host usamos FRR para anunciar o IP alocado via BGP
Em relação aos cenários de falha em novos datacenters, já testamos derrubando disjuntores, e com isso descobrimos que o balanceamento de fases estava desalinhado. Em outro site, entramos com uma câmera térmica
O site de AMS entra no ar na semana que vem, e o objetivo é ver até onde conseguimos forçar um fabric de switches totalmente preenchido
Bom artigo. Quando se precisa de velocidade de 100G, o Google cobra um preço realmente pesado. É quase ofensivo
Por exemplo, um Dedicated Interconnect de 100G redundante custa cerca de US$ 35 mil por mês, sem incluir VLAN attachment, custos de cross-connect em colocation, trânsito etc. Além disso, o VLAN attachment tem limite máximo de 50G
Comparando esse custo, com o mesmo dinheiro dá para comprar dois switches Arista novos de 32 portas 100G
Na América do Norte, dá para conseguir um circuito WAN de 100G, ou seja, um Wavelength gerenciado, por menos de US$ 5 mil por mês. Se for em uma área metropolitana local, também é possível conseguir fibra apagada por menos e rodar na velocidade que quiser