Les serveurs doivent-ils avoir leur fuseau horaire défini sur GMT / UTC? [fermé]

Ce n'est peut-être pas un gros problème pour les petits magasins qui n'ont qu'un ou quelques sites, mais pour les grandes organisations, c'est quelque chose qui m'intéresse.

Quels sont les avantages et les inconvénients d'avoir tout / la plupart de votre serveur en UTC? Cela contribuerait certainement à la création de rapports et à la journalisation centralisée. Également avec corrélation d'événements pour le dépannage ou l'audit de sécurité. Il ne faudrait pas non plus s'inquiéter autant des changements d'heure d'été.

Un inconvénient pourrait être que la planification d'événements automatisés (par exemple, cron) peut prendre un peu de temps si vous voulez qu'il exécute quelque chose à "4 heures du matin" dans l'heure locale et géographique. Pour la machine Unix-y, vous pouvez toujours avoir des utilisateurs dans le fuseau horaire local en définissant "TZ" dans / etc / profile, mais pour les utilisateurs de Windows qui RDesktop dans un serveur (pour une raison quelconque), sont-ils bloqués à regarder UTC?

Comme pour la plupart des choses, "cela dépend".

• Tous vos administrateurs / utilisateurs sont-ils dans le même fuseau horaire? Peut-être que leur TZ serait approprié.
• Les machines interagissent-elles avec l'environnement local? TZ local pourrait être bon.
• Tous les journaux sont-ils extraits vers un emplacement central pour analyse? L'UTC pourrait vous y aider.
• Les machines communiquent-elles les unes avec les autres lorsque le temps compte? L'UTC peut aider à prévenir les problèmes de non-concordance stupides.
• Le fournisseur du système d'exploitation (plus probable pour les équipements réseau) a-t-il une suggestion? Considérez cela.
• DST vous ennuiera-t-il? Utilisez UTC.
• Selon vous, qu'est-ce qui vous facilitera la vie? Utiliser ça.

J'ai fait toutes les options (local, UTC, arbitraire mais cohérent) et je préfère "l'heure locale au bureau à domicile pour toutes les machines" car c'est là que se trouvaient les administrateurs système et les utilisateurs, même si les machines étaient dispersées dans le monde entier. .

Nous avons tout réglé sur GMT, cela rend la corrélation des fichiers journaux entre les systèmes plus simple.

Mais je pense que nous devrions abandonner les fuseaux horaires et tous utiliser GMT pour tout.

Comme d'autres l'ont dit, cela dépend. Un très grand groupe avec une longue et vaste expérience en la matière a pesé. Le groupe est constitué par les forces militaires du monde entier et elles utilisent l'UTC (GMT).

Une autre chose à considérer. Si ces systèmes prennent en charge le code d'application, vous devez savoir si les applications sont sensibles au fuseau horaire. Dans certains des forums de programmation auxquels je participe, je suggère que la date et l'heure soient toujours stockées en UTC dans la base de données et donne à l'utilisateur final la possibilité de voir la date et l'heure.

Je travaille pour une très grande société d'hébergement et nous avons des centres de données dans le monde entier. Nous définissons généralement l'heure de la machine sur l'heure du centre de données local, puis utilisons le fuseau horaire où se trouve tout notre personnel de support comme l'heure universelle à laquelle les choses sont converties lors de l'utilisation d'outils, etc.

Comme d'autres l'ont dit, il n'y a pas de bonne réponse, mais c'est la méthode que nous utilisons :)

La politique indique ici que toutes les machines sont placées dans leur fuseau horaire local (c'est-à-dire leur emplacement physique). La seule chose délicate est de corréler les entrées du journal des événements (windows machiens) car l'heure est donnée nlocal - la plupart des autres fichiers journaux écrivent l'heure en UTC de toute façon.

mais pour les utilisateurs de Windows qui RDesktop dans un serveur (pour une raison quelconque), sont-ils bloqués à regarder UTC?

Pas totalement sûr, mais je pense que oui - le fuseau horaire est logiquement un paramètre de niveau machine.

Nous avons des machines physiquement situées dans un fuseau horaire qui sont définies pour 3 heures à l'avance en raison de l'application qu'elles prennent en charge.

Nous avons également des développeurs qui créent des logiciels qui attendent une synchronisation inférieure à cinq secondes entre les serveurs, des développeurs qui s'appuient implicitement sur le temps AD pour la synchronisation, et qui ne se soucient pas d'écrire des routines de vérification des erreurs ou de gestion des cas non synchronisés, et qui affirment que les échecs ultérieurs sont la faute des administrateurs pour ne pas maintenir le temps réseau au niveau qu'ils imaginaient.

Ne fais pas ce qu'on a fait. Cela vous rendra amer.

Pour ajouter à la discussion, nous avons des bureaux disséminés dans le monde entier et chacun d'eux a son propre ensemble de serveurs Web, d'application et de base de données, avec des branches d'application différentes pour chacun d'eux également, donc le fuseau horaire local est une bonne idée tout en parlant dans tout le pays. Pour les serveurs américains, nous nous dirigeons vers l'heure centrale pour que tous les emplacements correspondent à notre centre de données principal, car l'utilisation de différents fuseaux horaires pour les serveurs d'applications et les bases de données est difficile pour les développeurs.

L'App Yeller a récemment publié un article de blog conseillant à tous les administrateurs système d'utiliser l'UTC. Voici un extrait:

Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC.

Blagues à part, cela signifie essentiellement que l'utilisation uniquement de l'UTC signifie ne pas se soucier de l'heure d'été (DST) et des bogues que cela entraîne.