Compromissos operacionais
Tempos de resposta, um canal compartilhado no Slack, aviso prévio de manutenção, um inventário de referência e tratamento de falhas de hardware, definidos por escrito na nossa especificação de entrega do HGX B300.
Nossos compromissos operacionais definem por escrito com que rapidez respondemos, como mantemos você informado, com quanta antecedência avisamos e como tratamos falhas de hardware. Eles são a seção 15 da nossa especificação de entrega, a base de toda proposta de HGX B300.
Os compromissos em uma tabela
Cada compromisso é um número em minutos, dias ou meses, para que você possa comparar o que fazemos com ele.
| Compromisso | Métrica |
|---|---|
| Incidente reconhecido e comandante de incidentes designado | Em até 15 minutos |
| Atualizações enquanto um incidente estiver aberto | Pelo menos a cada 60 minutos |
| Operações de rede acionadas, a qualquer hora | Em até 15 minutos |
| Engenharia da instalação ou remote hands acionados | Em até 45 minutos |
| Relatório pós-incidente por escrito após um incidente que afete o cliente | Em até 7 dias |
| Aviso prévio antes de manutenção planejada de alto risco | Pelo menos 7 dias |
| Mudanças de inventário e de estado visíveis para você | Em até 5 minutos |
| Filtragem de DDoS ativada via BGP | Em até 5 minutos |
| Alterações de regras do firewall de borda | Em até 1 dia útil |
| Retenção da telemetria operacional e do histórico de incidentes e de estado | 30 dias, e 12 meses |
Não publicamos percentuais de uptime. Publicamos o que fazemos quando algo dá errado, e com que rapidez.
Suporte: um canal compartilhado e um responsável designado
Você trabalha diretamente com as pessoas que operam o seu cluster, em um canal compartilhado no Slack que fica aberto o tempo todo.
Um canal compartilhado no Slack
Aberto o tempo todo, com nosso comandante de incidentes, operações de rede, operações das instalações e remote hands.
Um responsável técnico designado para a conta
Uma pessoa designada na 1Legion que é responsável pela sua conta.
Duas formas de contatar o plantão
Duas formas independentes e testadas de contatar um plantonista qualificado, 24 horas por dia, todos os dias.
O canal reúne em um só lugar as pessoas afetadas por um problema e as pessoas que o resolvem. A segunda forma de contatar o plantão, independente, existe para o caso de o problema estar na primeira.
Incidentes, do primeiro alerta ao relatório pós-incidente
Os incidentes seguem uma sequência: reconhecimento e um comandante de incidentes em até 15 minutos, engenheiros acionados, atualizações pelo menos a cada 60 minutos e um relatório pós-incidente por escrito em até 7 dias corridos após cada incidente com impacto para o cliente.
Reconhecer
Reconhecemos o incidente e designamos um comandante de incidentes em até 15 minutos. O comandante de incidentes é a única pessoa que coordena a resposta.
Acionar
As operações de rede são acionadas em até 15 minutos, a qualquer hora, e a engenharia das instalações ou o remote hands, em até 45 minutos.
Atualizar
Você recebe atualizações pelo menos a cada 60 minutos enquanto o incidente estiver aberto.
Relatório pós-incidente
Em até 7 dias corridos após cada incidente com impacto para o cliente, você recebe um relatório pós-incidente por escrito.
Um relatório pós-incidente é um relato por escrito de um incidente: o que aconteceu, por que aconteceu e o que está sendo feito para que não aconteça de novo.
Manutenção, mudanças e inventário
Trabalhos planejados que envolvem risco são anunciados com pelo menos 7 dias corridos de antecedência, as mudanças passam pela gestão de mudanças por escrito e um inventário de referência registra o seu cluster até o nível dos cabos.
Aviso prévio de manutenção
O aviso prévio se aplica à manutenção de alto risco e não emergencial, e dá a você tempo para mover tarefas ou fazer um checkpoint antes do início do trabalho. Trabalhos emergenciais ficam fora do período de aviso prévio. Do lado das instalações, pedimos aos data centers que usamos aviso prévio de 14 dias para manutenção de risco.
Gestão de mudanças e acesso
Gestão de mudanças por escrito significa que as alterações no seu cluster seguem um processo documentado e deixam um registro por escrito. O acesso fora de banda, o caminho de gerenciamento que chega a um servidor pelo BMC, abaixo do sistema operacional, é auditado.
O inventário
Mantemos um inventário de referência de cada rack, nó, GPU, NIC, disco, switch, porta, transceptor e cabo, com uma exportação legível por máquina para você. As mudanças de estado ficam visíveis em até 5 minutos. A detecção de divergências compara o cluster com a linha de base acordada, para que uma alteração que ninguém planejou apareça.
Estamos desenvolvendo nosso próprio software de plataforma para inventário, monitoramento e automação do burn-in, com componentes de código aberto. Um portal do cliente e uma API pública fazem parte desse trabalho e ainda não estão disponíveis.
Tratamento de falhas de hardware
Encontramos e corrigimos falhas de hardware, das instalações, de refrigeração e de fabric, e colocamos imediatamente em quarentena uma GPU com falha fatal.
| Falha | O que significa | O que fazemos |
|---|---|---|
| XID 79 | A GPU caiu do barramento e parou de responder | Colocar em quarentena imediatamente |
| XID 48 | O driver informou um erro de ECC de bit duplo | Colocar em quarentena imediatamente |
| Erro de ECC de bit duplo | Um erro não corrigível na memória da GPU | Colocar em quarentena imediatamente |
| Falha de remapeamento de linhas | A GPU não conseguiu remapear uma linha de memória com defeito para uma linha reserva | Colocar em quarentena imediatamente |
| XID 13 ou XID 31 recorrente | Uma exceção do mecanismo gráfico ou uma falha de página na memória da GPU | Agir após um número acordado de ocorrências |
| Desgaste de disco NVMe | Discos flash se desgastam à medida que dados são gravados neles | Substituir antes dos limites de durabilidade |
| Travamento do NCCL | Uma operação coletiva para de avançar | Correlacionar com eventos do fabric |
| Suspeita de corrupção silenciosa de dados | Resultados incorretos sem nenhum erro informado | Manter o nó em quarentena |
A quarentena tira o hardware afetado de operação até que a falha seja corrigida, para que nenhuma tarefa seja alocada nele. XID 13 e XID 31 podem vir da aplicação, e não da GPU, por isso agimos sobre eles quando se repetem além de um número acordado. Quando uma tarefa NCCL trava, verificamos os eventos do fabric do mesmo momento, para que uma falha de link ou de switch por trás do travamento possa ser encontrada. A corrupção silenciosa de dados está entre as falhas mais difíceis de perceber, porque nada a reporta, e é por isso que um nó suspeito permanece em quarentena. Os discos NVMe são substituídos antes de atingirem seus limites de durabilidade, e não depois de falharem.
Serviço do appliance de armazenamento
Se o seu cluster usa um appliance de armazenamento gerenciado pelo fornecedor, a especificação assume o compromisso de um projeto com suporte do fornecedor, com escalonamento 24/7, throughput e latência contratados por camada, uso e cotas visíveis e recuperação testada.
- Projeto com suporte do fornecedor. O appliance, da VAST Data, WEKA ou DDN, é construído segundo um projeto com suporte do próprio fornecedor.
- Escalonamento 24/7. Um problema de armazenamento pode ser escalonado a qualquer hora.
- Throughput e latência por camada. Cada camada de armazenamento tem throughput e latência contratados, para que você possa planejar tarefas e checkpoints com base em números conhecidos.
- Uso e cotas. O uso e as cotas são visíveis, para que a capacidade não se esgote sem que ninguém perceba.
- Recuperação testada. A recuperação é testada, e não apenas documentada.
As duas opções de armazenamento, o appliance e os nós de armazenamento para o seu próprio software, são descritas na nossa página Armazenamento e rede.
Telemetria e histórico
Coletamos a telemetria de hardware fora de banda e mantemos a telemetria operacional por pelo menos 30 dias e o histórico de incidentes e de estado por pelo menos 12 meses.
A telemetria fora de banda vem dos BMCs dos servidores via Redfish, por isso continua reportando quando o sistema operacional não reporta. A telemetria de rede e das instalações é coletada onde estiver disponível. Pelo menos 12 meses de histórico de incidentes e de estado significam que uma falha que se repete com meses de intervalo ainda pode ser rastreada até suas ocorrências anteriores.
Antes que qualquer parte disso se aplique, todo cluster passa pelos testes descritos na nossa página Burn-in e aceite. Se você também quiser que operemos a camada de plataforma nos seus servidores, veja Kubernetes gerenciado.
Perguntas que os compradores fazem
Isto é um SLA com percentual de uptime e créditos de serviço?
Não. Não publicamos percentuais de uptime nem créditos de serviço. Em vez disso, publicamos os compromissos desta página: tempos de resposta, intervalos de atualização, prazos de aviso prévio, relatórios e tratamento de falhas. Sua proposta define as condições do seu contrato.
Com que rapidez vocês respondem a um incidente?
Os incidentes são reconhecidos e um comandante de incidentes é designado em até 15 minutos. As operações de rede são acionadas em até 15 minutos, a qualquer hora, e a engenharia das instalações ou o remote hands, em até 45 minutos.
Como entramos em contato com vocês fora do horário comercial?
Pelo canal compartilhado no Slack, que fica aberto o tempo todo, ou por duas formas independentes e testadas de contatar um plantonista qualificado, 24 horas por dia, todos os dias.
Com quanta antecedência vocês avisam sobre manutenções?
Pelo menos 7 dias corridos para manutenção de alto risco e não emergencial.
O que acontece quando uma GPU tem uma falha fatal?
Falhas fatais de GPU levam à quarentena imediata: XID 79, XID 48, erros de ECC de bit duplo e falhas de remapeamento de linhas. Depois, encontramos e corrigimos a falha.
Conte o que você precisa rodar.
Informe o hardware, o número de servidores, o prazo e a data de início. Você recebe uma proposta por escrito baseada na nossa especificação de entrega.