Solutions informatiques
Construit une base de temps unifiée et reproductible pour les services critiques, garantissant la continuité, la stabilité et la haute disponibilité des centres de données.
Face à l'IA, au HPC, à l'edge computing et à d'autres scénarios de haute performance, l'échelle de la puissance arithmétique ne cesse de croître, et ce qui détermine réellement la stabilité du système, la cohérence de l'ordre et la capacité à collaborer sur des tâches est une capacité de base souvent négligée mais cruciale : le temps.
Lorsque la taille de la grappe passe de dizaines de cartes à des milliers de cartes, des aspects clés tels que les fenêtres de traitement par lots du GPU, les barrières de synchronisation, l'ordre causal des flux d'événements et l'ordonnancement des tâches d'inférence exigent que l'ensemble du système maintienne le même niveau d'efficacité et d'efficience.Battements de temps harmonisés et reproductibles. Si le temps n'est pas cohérent, le système informatique connaîtra un chaos dans les files d'attente, une mauvaise classification des fenêtres, un désordre dans les tâches, un désordre dans la chaîne d'audit et d'autres problèmes difficiles à localiser en cas de forte charge. Par conséquent, la reconstruction de la base temporelle de l'industrie informatique est une base d'ingénierie inévitable pour l'ère de l'IA.
Pourquoi reconstruire la "base de temps" ?
NTP est largement utilisé dans les systèmes informatiques depuis une dizaine d'années, mais son modèle "demande-réponse" de la couche application traduit la gigue des liaisons, les files d'attente et l'incertitude en erreurs de synchronisation qui peuvent facilement passer de la microseconde à la milliseconde. Pour l'IA/HPC, c'est un désastre.
L'introduction du protocole PTP a modifié la manière dont le temps est transmis :
Horodatage du "noyau de l'hôte" jusqu'auNIC / PHY / Switch (BC/TC)
Chaque gigue est corrigée
Avec SyncE, la fréquence et la phase peuvent être renforcées ensemble.
Par conséquent, la précision de la microseconde devient la norme et les nanosecondes ne sont plus rares
Risques liés à l'incohérence du calendrier
Mauvaise classification des fenêtres de lots GPU/CPULe lot de formation se divise et se désaligne, ce qui entraîne une dégradation du débit.
Barrières de synchronisation déclenchées précocement ou tardivementLes formations multi-appareils : entraînent un ralentissement de l'efficacité de la formation multi-appareils
Fenêtre de calcul du streaming Désordre: : Traitement des événements "deux fois le même lot de données/traitement manqué".
Les transactions et les journaux ne sont pas en ordreDifficulté à examiner le planificateur et le système d'audit
Raisonnement Erreur d'appréciation du délai d'attente du serviceLes demandes rejetées prématurément ou renvoyées tardivement : Les demandes rejetées prématurément ou renvoyées tardivement
Contestation des ressources entre nœuds: incapacité du système de répartition à allouer correctement les ressources en fonction du budget-temps.
Ces problèmes sont d'autant plus fréquents que la taille de la grappe est importante et que la charge est élevée.
Calculer l'architecture temporelle de l'industrie : aligner puis resserrer lorsque les intranets sont auto-alimentés
Autoprovisionnement de l'intranet en mode maître
1. antenne GNSS (BeiDou/GPS) directement dans la salle des machines
2. heure unifiée fournie par le serveur d'horloge local
3. éviter le détournement du réseau public et la gigue temporelle des tiers
L'équipement d'inventaire n'est pas mis à niveau, le NTP est d'abord utilisé pour l'assembler.
Dans la première phase, NTP est utilisé pour mettre en file d'attente le nombre total de serveurs. Pas d'impact sur le réseau existant, pas d'interruption des activités.
Basculement progressif des nœuds de calcul centraux vers le PTP
Adoption de la norme G.8275.1 (L2 + SyncE) pour le même campus
G.8275.2 pour les réseaux inter-campus, inter-tiers 3
Configurer l'architecture multi-GM maître/standby par numéro de domaine/priorité
Aperçu des solutions
Antenne GNSS → serveur d'horloge (OCXO/rubidium) → distribution PTP (L2 + SyncE) aux commutateurs/hôtes ; compatible avec les hôtes de stock orientés NTP.
GNSS par emplacement + GM local, politique de synchronisation des domaines et commutation des priorités, reprise après sinistre hors site via UDPv4 pour maintenir la pénétration et la cohérence.
Les domaines PTP sont divisés par entreprise/cluster, et la formation/l'inférence/le stockage sont contrôlés séparément pour garantir une faible gigue et des possibilités de précision de l'ordre de la nanoseconde.
Accès des appareils au réseau existant - chemin d'atterrissage en trois étapes
phase préparatoire
- Confirmer la position, l'alimentation et le champ de vision de l'antenne GNSS
- Le commutateur prend-il en charge les horodatages matériels PTP, BC/TC ?
- Configuration des VLAN, du routage, des liens, des ports de gestion/service
- La politique de sécurité ne libère que les ports de synchronisation et de gestion à distance
phase d'ouverture
- Mise sous tension de l'appareil → Configuration du fuseau horaire → Réglage des paramètres de mise en attente
- Lancer l'acquisition du GNSS.
- Ouvrir NTP pour inventorier les hôtes
- Activation de PTP (L2/SyncE ou UDPv4) par domaine
Décharge et retour
- Accéder d'abord à un petit nombre de serveurs pour vérifier le biais/la gigue.
- Puis étendre progressivement à l'ensemble de la grappe
Préparation des sources de temps de contournement en tant que solution de protection de l'entreprise
Sécurité : prendre en main les liens temporels
Les serveurs d'horloge sont déployés sur l'intranet et ne dépendent pas de l'heure publique sur l'extranet.
Ports réduits au minimum, seules les interfaces de synchronisation et d'exploitation et de gestion sont ouvertes.
SNMP utilise v3, les API utilisent Token
Toutes les modifications sont enregistrées dans le journal d'audit
L'uniformité de l'heure est la meilleure base médico-légale, et les journaux peuvent être comparés les uns aux autres.
Le temps n'est pas seulement un piédestal de performance, mais aussi un piédestal de sécurité.
O&M : Garder l'état du temps "sous les yeux"
Surveillance visuelle : verrouillage GNSS, écart UTC, état du processus PTP/NTP, courbes d'écart/de gigue, état de maintien CPU/mémoire/température/oscillateur.
Éléments d'alarme : perte de l'étoile GNSS, écart supérieur au seuil, basculement du maître et de la sauvegarde, changement de trajectoire de synchronisation.
Foire aux questions (FAQ)
Les horloges des nuages publics peuvent-elles remplacer les horloges locales ?
Ce n'est pas possible. Ce qu'il faut, c'est un temps "uniforme et vérifiable", et non pas "il y a un temps".
Faut-il changer les serveurs de base ?
Non. NTP rassemble d'abord et PTP met ensuite progressivement à niveau les domaines clés.
Pourquoi doit-il s'agir de PTP ?
Comme le PTP réduit l'erreur de millisecondes à microsecondes/nanosecondes, il constitue une base nécessaire pour l'IA/HPC.
Vous souhaitez faire passer la précision temporelle de votre centre de données de "fonctionnel" à "socle de qualité technique pouvant faire l'objet d'un nouveau test" ? Contactez nous pourProgrammes d'évaluation et d'atterrissage personnalisésIl comprend l'adaptation du réseau, le déploiement pilote, la surveillance et la fourniture de services d'exploitation et de maintenance.