AMD EPYC Turin: Escolher o processador de servidor adequado para os prestadores de serviços de alojamento

Entender bem o AMD EPYC Turin

AMD EPYC Turin refere-se ao Geração EPYC 9005 de processadores para servidores. A AMD apresentou-os em outubro de 2024 como a quinta geração EPYC; a família inclui modelos com núcleos Zen-5 e Zen-5c.

Para os fornecedores de alojamento, o Turin não é uma CPU isolada com características de desempenho uniformes. A gama de modelos varia entre oito e 192 núcleos por processador. A escolha do modelo adequado depende do facto de haver muitas solicitações independentes de clientes a serem processadas em paralelo, de aplicações específicas necessitarem de tempos de resposta curtos ou de as máquinas virtuais consumirem, sobretudo, muita memória.

Entre as opções está também a questão da Número de bases: Um servidor com um único processador oferece uma combinação diferente de capacidade de processamento, ligação à memória e possibilidades de expansão em comparação com uma plataforma de dois soquetes. Nem todos os modelos estão concebidos para ambas as variantes; de acordo com a ficha técnica, os processadores com o sufixo «P» são concebidos para sistemas de soquete único.

A pré-seleção começa, portanto, pela composição concreta da carteira de clientes e pelos requisitos em termos de RAM, unidades NVMe e rede. Um alojamento VPS com elevada densidade, por exemplo, necessita de reservas para máquinas virtuais ativas em simultâneo, enquanto um servidor de bases de dados pode, além disso, responder às necessidades de armazenamento e de E/S. As licenças de software e as autorizações do fabricante do servidor também fazem parte do planeamento.

O simples facto de haver mais núcleos não indica, por si só, quantos servidores existentes podem ser substituídos. Para tal, o fornecedor necessita de perfis de carga e valores de medição comparáveis do hardware de alojamento existente, bem como de uma reserva de falha definida. Sem esta base, é possível selecionar um modelo, mas não é possível determinar uma taxa de consolidação fiável.

Compreender os núcleos, os chiplets e a frequência de clock

Turim utiliza um Concepção de chiplets: As unidades de computação e um die de E/S separado estão ligados através da AMD Infinity Fabric. O die de E/S fornece, entre outras coisas, as ligações à memória principal e às entradas e saídas. Na prática, para o planeamento de servidores, isto significa que não são apenas os núcleos que contam, mas também a ligação aos recursos partilhados.

O Zen 5 e o Zen 5c diferem na sua conceção e na organização dos núcleos. O Zen 5c permite a maior densidade de núcleos dentro desta geração; no entanto, isso não implica uma classificação geral em termos de desempenho. Uma combinação de máquinas virtuais (VM) altamente paralelizada e uma aplicação com poucas tarefas sensíveis à latência podem favorecer modelos diferentes.

O EPYC 9965 possui 192 núcleos Zen-5c e 384 threads, enquanto o EPYC 9755 possui 128 núcleos Zen-5 e 256 threads. A AMD indica um boost máximo de até 3,7 GHz para o 9965 e de até 4,1 GHz para o 9755. Estes valores refletem diferentes prioridades, mas não substituem uma comparação com base no próprio perfil de carga.

O indicado impulso máximo Em particular, não existe uma frequência de funcionamento constante garantida para todos os núcleos. A frequência atingida sob carga depende, entre outros fatores, da carga e das condições de funcionamento. Por isso, para uma decisão de alojamento, a largura de banda e os tempos de resposta num conjunto definido de aplicações são mais reveladores do que o valor de pico isolado.

O número de threads, que é o dobro do esperado, resulta da tecnologia SMT: um núcleo físico disponibiliza dois threads lógicos. No entanto, estes partilham os recursos do núcleo; 384 threads não correspondem a 384 núcleos físicos, nem a uma duplicação automática da capacidade de computação. Para determinar se a SMT e a sobrealocação de recursos da CPU são úteis, é necessário avaliar a carga de clientes ativos em simultâneo.

A memória e as E/S limitam a capacidade

Muitos núcleos de CPU requerem uma configuração de memória adequada. Segundo a AMD, o EPYC 9005 suporta até doze canais de memória DDR5 por CPU. Para um anfitrião de máquinas virtuais, não é apenas a capacidade total de RAM que conta: a distribuição dos módulos e a largura de banda de memória disponível também influenciam a capacidade de atender adequadamente os convidados ativos em simultâneo.

A ficha técnica indica, para os modelos listados, até DDR5-6400 a um DIMM por canal. A velocidade efetivamente utilizável depende da configuração de memória e da certificação da plataforma. Além disso, os até 6 TB de DDR5 mencionados na ficha técnica referem-se às configurações aí indicadas, com dois DIMMs por canal, e não constituem uma garantia para todos os servidores.

A utilização de mais módulos de RAM pode ser útil para atingir a capacidade necessária, mas altera a configuração a testar. Por isso, os fornecedores devem comparar o tamanho e a configuração dos módulos pretendidos com a lista de aprovação do fabricante do servidor, em vez de somarem independentemente uns dos outros os valores máximos de capacidade e velocidade indicados na ficha técnica.

Para unidades NVMe e placas de rede, é também necessário o Ligação PCIe decisivo. A AMD refere até 128 pistas PCIe 5.0 para sistemas de soquete único e até 160 para servidores de dois soquetes. O número de ligações que uma placa específica disponibiliza efetivamente depende do design da plataforma e da utilização das ligações; o máximo de 2P não se aplica automaticamente a um anfitrião de 1P.

Por isso, durante a configuração, vale a pena ter em conta a interação entre os componentes: mais unidades NVMe podem ocupar ligações adicionais, enquanto as placas de rede de alta velocidade também têm de ser ligadas. O CXL 2.0 faz parte das capacidades da plataforma, mas não é uma funcionalidade automaticamente disponível em todos os servidores. É necessário verificar a compatibilidade do equipamento, do firmware e do sistema operativo para o sistema escolhido.

Comparar planos de alojamento da Turin

A família EPYC 9005 apresenta diferentes pontos fortes: o 9965 aposta na densidade máxima de núcleos, enquanto o 9575F visa uma frequência mais elevada. Na escolha, não conta apenas a CPU, mas sim a combinação entre o modelo específico, o tipo de soquete e a carga de trabalho. A tabela seguinte compara quatro modelos com base em dados da AMD.

O 9965 disponibiliza um número particularmente elevado de núcleos físicos para tarefas independentes. Isto pode ser interessante no caso de um conjunto de máquinas virtuais altamente paralelizadas, desde que a memória e as E/S consigam acompanhar o ritmo. O 9755 oferece menos núcleos, mas um boost máximo mais elevado e mais cache L3 total. A partir destes dados, por si só, não é possível estabelecer uma classificação definitiva para aplicações de alojamento.

O 9575F é uma opção a considerar quando determinadas etapas de trabalho exigem tempos de resposta curtos. O seu impulso máximo No entanto, não se trata de uma frequência garantida de forma permanente para todos os núcleos. O facto de ser mais económico do que um modelo com mais núcleos depende, entre outros fatores, das solicitações simultâneas e do modelo de licença.

No modelo 9655P, isso limita o Sufixo P a compatibilidade do soquete com sistemas de soquete único. Por conseguinte, este modelo não é uma opção para um servidor de dois soquetes. Uma comparação mais abrangente entre plataformas deveria incluir configurações e medições concretas; para tal, o artigo sobre a Escolha da plataforma entre AMD EPYC e Intel Xeon mais orientações.

Atribuir cargas de trabalho de alojamento e pontos de estrangulamento

A CPU de um servidor tem de ser adequada aos serviços em execução simultânea. Na hospedagem partilhada, surgem muitas solicitações independentes; nas máquinas virtuais, sistemas operativos inteiros competem pelos recursos; e as bases de dados reagem de forma sensível aos acessos à memória ou à latência de armazenamento, dependendo da carga de trabalho. A visão geral que se segue traduz estas diferenças em questões de avaliação para o dimensionamento.

No caso do alojamento partilhado, o número de workers ativos em simultâneo é tão relevante quanto a duração de cada pedido. Uma elevada utilização da CPU pode ser aceitável se a taxa de transferência for boa; no entanto, por si só, isso não indica se os clientes têm de esperar muito tempo. Por isso, as distribuições dos tempos de resposta e as taxas de erro em níveis de carga definidos devem ser incluídas na comparação.

No caso das bases de dados, o Cache L3 apenas uma parte do quadro. O modelo 9755 possui um total de 512 MB, enquanto o 9965 possui um total de 384 MB. Estes valores dos modelos não comprovam qualquer vantagem em termos de bases de dados: o tamanho dos conjuntos de dados, os padrões de acesso, a distribuição do trabalho e a configuração da RAM influenciam a frequência com que são necessários dados de outros níveis de memória.

Um serviço Redis gerido complementa o conjunto de aplicações, por exemplo, como cache. Para tal, os fornecedores têm de ter em conta, para além dos recursos de CPU, sobretudo a memória disponível e os requisitos do serviço em questão. O artigo sobre Redis 8 e decisões de atualização para fornecedores de alojamento aborda, entre outros aspetos, os limites de armazenamento e o funcionamento desses serviços.

Para uma comparação justa entre modelos, a combinação de máquinas virtuais (VM-Mix), a capacidade de RAM, o armazenamento e os níveis de carga devem ser, na medida do possível, comparáveis. Caso contrário, não será possível atribuir de forma significativa as diferenças nos tempos de resposta ou na taxa de transferência à escolha da CPU. Além disso, uma resposta mais rápida a uma consulta individual e uma taxa de transferência global mais elevada são objetivos distintos, que podem ser ponderados de forma diferente no planeamento das tarifas.

Planear a capacidade da VM a título de exemplo

Um exemplo de cálculo permite visualizar as ordens de grandeza: um host com um EPYC 9965 dispõe de 192 núcleos físicos e 384 threads. Se forem configuradas 48 máquinas virtuais (VM), cada uma com quatro vCPUs, o resultado é 48 × 4 = 192 vCPUs atribuídas. Trata-se de um cálculo de atribuição e não de uma medição do desempenho alcançável das máquinas virtuais.

A vCPU não se trata, necessariamente, de um núcleo físico reservado em exclusivo. O hipervisor aloca processadores virtuais nos processadores lógicos disponíveis; a execução efetiva depende das máquinas virtuais que estão a funcionar em simultâneo e dos recursos que lhes são atribuídos. Além disso, os 384 threads do processador não correspondem a 384 núcleos físicos independentes.

Para o Sobre-reserva Deve, em primeiro lugar, determinar qual a carga simultânea que espera e qual o desempenho prometido por um plano. Um número mais elevado de vCPUs atribuídas pode funcionar quando os picos de carga raramente coincidem, mas aumenta o risco de tempos de espera quando muitos utilizadores estão a processar dados em simultâneo. Verifica esta hipótese com base na composição real da clientela, em vez de te baseares apenas no número de threads.

Em seguida, calcula-se a necessidade de memória separadamente: soma-se a RAM prevista para as máquinas virtuais e tem-se em conta, adicionalmente, as necessidades do hipervisor, bem como as reservas operacionais. O cálculo da CPU não indica se o anfitrião disponibiliza RAM suficiente nem se a largura de banda de memória necessária é suficiente quando há máquinas convidadas ativas em simultâneo.

O mesmo se aplica ao armazenamento e à rede. Muitas máquinas virtuais podem aceder simultaneamente a unidades NVMe ou transferir dados; neste contexto, além da taxa de transferência total, as latências de E/S e os picos de carga são também relevantes. Por isso, tenha em conta a ligação e o desempenho das unidades e placas de rede efetivamente utilizadas.

Afinal, é necessário ter uma reserva para manutenção e falhas. Se um host remanescente tiver de acolher máquinas virtuais adicionais após a falha de outro, a ocupação normal não pode já estar a consumir todos os recursos necessários para esse efeito. O exemplo com 48 máquinas virtuais não define nem um limite de ocupação seguro nem uma taxa de consolidação; ambos têm de ser avaliados com base no ambiente específico.

Preparar a plataforma e a virtualização

Comece o planeamento da plataforma com o modelo específico de CPU e a questão de saber se são necessários um ou dois soquetes. As necessidades em termos de núcleos, RAM e E/S têm de se adequarem, em conjunto, ao sistema anfitrião pretendido. Um modelo P, como o EPYC 9655P, foi concebido para um soquete e, por isso, não é adequado para uma configuração de dois soquetes.

Em seguida, verifica a Aprovação do fabricante para a CPU, a placa-mãe e a BIOS. Embora o Turin utilize o soquete SP5, um servidor SP5 já existente não suporta, só por esse motivo, todos os modelos 9005. A fonte de alimentação e o sistema de refrigeração também têm de ser compatíveis com a CPU selecionada e com a caixa prevista.

Planifique os módulos de RAM de acordo com a capacidade, a configuração dos canais e as especificações do fabricante do servidor. A isto acrescentam-se as unidades NVMe e as placas de rede necessárias: o que é determinante não é apenas o seu número, mas também quais os slots ou compartimentos para unidades que estão ligados no sistema em questão. Desta forma, é possível verificar, antes de efetuar a encomenda, se a combinação pretendida é de facto possível na plataforma.

No caso de máquinas virtuais confidenciais de clientes, é possível SEV-SNP complementar a proteção da memória da VM com mecanismos de integridade. O Trusted I/O através do TDISP é outro componente possível para o acesso a dispositivos. No entanto, a possibilidade de isso se traduzir numa oferta útil depende da combinação entre o firmware, o hipervisor, o sistema operativo convidado e, se for o caso, os dispositivos.

Antes de confirmar a aquisição de um produto, deve também esclarecer como os convidados são configurados, certificados e geridos, bem como quais as restrições aplicáveis às funcionalidades de VM oferecidas. Uma funcionalidade da CPU, por si só, não garante a compatibilidade de toda a pilha nem protege contra todos os ataques. Por isso, documenta a configuração efetivamente suportada e mantém-na atualizada sempre que houver atualizações.

Avaliar o funcionamento e identificar pontos de estrangulamento

Para fazer uma comparação com o hardware de alojamento existente, precisas de um sistema compreensível perfil de carga: aproximadamente a mesma combinação de máquinas virtuais, volumes de dados semelhantes e tipos de pedidos definidos. Registe a configuração da RAM, do armazenamento, da rede e do software. Só assim será possível distinguir posteriormente se um desvio está mais relacionado com a CPU ou com outra alteração no sistema.

Analise vários níveis de carga, em vez de apenas um valor de pico. Registe, para tal, o débito, a distribuição dos tempos de resposta e as taxas de erro: um débito mais elevado tem pouco valor para um serviço de alojamento se, ao mesmo tempo, muitas solicitações ficarem lentas ou falharem. Defina antecipadamente quais os tempos de resposta e as taxas de erro que são aceitáveis para o serviço em questão.

Acompanhe, em paralelo, a utilização da RAM e o comportamento da memória, bem como a latência e a utilização do armazenamento e da rede. Se os tempos de resposta aumentarem, apesar de a CPU ainda apresentar reservas, pode ser que, por exemplo, outra parte da plataforma esteja a limitar o desempenho. Por outro lado, uma elevada utilização da CPU, por si só, não prova que os clientes estejam a ter uma má experiência de utilizador.

Se os tempos de resposta das máquinas virtuais forem anormais, verifique a simultaneidade prevista e a Sobrecarga da CPU. Em seguida, compare a configuração real da RAM, as definições do firmware e do hipervisor com a configuração planeada. Altere, na medida do possível, fatores específicos e repita o mesmo nível de carga, para que a causa não seja confundida com uma alteração simultânea na carga de trabalho.

A operação contínua inclui ainda boletins de segurança, atualizações de firmware, controlos de acesso e cópias de segurança verificáveis. A AMD também publica alertas sobre vulnerabilidades de segurança e medidas a tomar para os processadores EPYC; os operadores devem planear as atualizações adequadas fornecidas pelo fabricante do servidor. Após as operações de manutenção, verifique novamente se as funções de proteção e as configurações de convidados disponibilizadas estão disponíveis conforme previsto.

A aquisição e a rentabilidade são determinantes

Uma decisão de aquisição começa com a questão de saber se a plataforma existente continua a satisfazer os requisitos. Se a capacidade e as reservas forem suficientes, pode fazer sentido continuar a utilizá-la. Por outro lado, para uma atualização para o Turin, o modelo específico da CPU, o firmware e os restantes componentes têm de ser aprovados pelo fabricante do servidor; o facto de partilharem o soquete SP5 não é prova suficiente.

Compara um 1P-Host com uma configuração de 2P, com base nas necessidades totais de núcleos, RAM e portas. Não são necessários dois soquetes apenas devido a um número elevado de máquinas virtuais pretendido. Por outro lado, uma plataforma de um único soquete pode ser descartada se a combinação necessária de memória e E/S não puder ser acomodada no servidor escolhido.

No caso de muitas tarefas independentes e ativas em simultâneo, a densidade de núcleos pode ser um critério de seleção importante. Por outro lado, para aplicações sensíveis à latência, vale a pena analisar também modelos com frequência de clock mais elevada no próprio conjunto de aplicações. Além disso, calcule o modelo de licença específico: os custos por núcleo, soquete ou VM podem alterar a ordem de prioridade económica das plataformas.

O TDP não é uma medição do consumo de energia de um servidor completo. A AMD indica um TDP de 500 watts tanto para o EPYC 9755 como para o 9965; isso não permite determinar nem o consumo de energia sob a tua carga nem os custos anuais de energia. A memória RAM, as unidades de disco, a rede e o arrefecimento fazem parte da análise global do sistema.

Para uma comparação de energia e custos, analise o sistema na sua totalidade com níveis de carga representativos e tenha em conta as reservas necessárias. Deve comparar os custos de aquisição, as licenças de software e os custos operacionais ao longo do período de utilização previsto. Sem dados comparativos da situação atual, não é possível prometer nem uma poupança específica nem uma taxa de consolidação fiável.