Должны ли серверы иметь часовой пояс с GMT / UTC? [закрыто]

22

Это может не иметь большого значения для небольших магазинов, которые имеют только один или несколько сайтов, но для крупных организаций это то, что мне интересно.

Какие плюсы и минусы имеют все / большинство вашего сервера в UTC? Это, безусловно, поможет в отчетности и централизованном ведении журнала. Также с корреляцией событий для устранения неполадок или аудита безопасности. Также не нужно было бы беспокоиться об изменениях летнего времени.

Один недостаток может заключаться в том, что планирование автоматических событий (например, cron) может занять немного времени, если вы хотите, чтобы оно выполнялось в 4:00 по местному географическому времени. Для машины Unix-y вы все равно могли бы позволить пользователям находиться в местном часовом поясе, установив «TZ» в / etc / profile, но для пользователей Windows, которые RDesktop подключаются к серверу (по какой-либо причине), они застряли, глядя на UTC?


источник
Существует аналогичный (более старый) поток, работающий над sage-members: mailman.sage.org/pipermail/sage-members/2010/msg00592.html
adamo
И, конечно же, поскольку вы также опубликовали вопрос о членах sage, (новая) ветка mailman.sage.org/pipermail/sage-members/2010/msg01194.html :)
adamo
2
UTC один часовой пояс, чтобы управлять ими всеми ...

Ответы:

19

Как и в большинстве случаев, «это зависит».

  • Все ли ваши администраторы / пользователи находятся в одном часовом поясе? Возможно, их TZ будет уместным.
  • Взаимодействуют ли машины с местной средой? Местный ТЗ может быть хорошим.
  • Все журналы перенесены в центральное место для анализа? UTC может помочь там.
  • Общаются ли машины друг с другом так, чтобы время имело значение? UTC может помочь предотвратить глупые несоответствия.
  • Есть ли у поставщика ОС (скорее всего, для сетевого оборудования) предложение? Считают, что.
  • DST будет раздражать вас? Используйте UTC.
  • Как вы думаете, сделает вашу жизнь проще? Используйте это.

Я сделал все варианты (локальный, UTC, произвольный, но последовательный) и предпочел «местное время домашнему офису для всех машин», поскольку там были системные администраторы и пользователи, хотя машины были разбросаны по всему миру. ,

Люк
источник
4
Ну что ж - я бы добавил еще пару критериев. 1) Если у вас есть организации поддержки в нескольких часовых поясах, UTC везде может избежать путаницы (в этом случае установка часового пояса в «домашнем офисе» будет только раздражать людей в других офисах; не обращайте внимания на возникающую путаницу) когда наступает DST. 2) Если вам приходится иметь дело с международными поставщиками, такими как операторы связи, многие из них работают в UTC; отсутствие необходимости конвертировать метки времени в журналах при их отправке сэкономит много времени.
Мурали Суриар
Я работал на разных часовых поясах с разными серверами. Когда-то у нас были серьезные проблемы с проектом, в котором данные хранились с часовым поясом сервера, установленным на DST и GMT. Не легко исправить. Нелегко. UTC - твой друг :)
Джон Хант
6

Мы устанавливаем все в GMT, это упрощает корреляцию файлов журналов в разных системах.

Но я думаю, что мы должны отбросить часовые пояса, и все используют GMT для всего.

Рональд Поттол
источник
3

Как уже говорили другие, это зависит. Взвешена очень большая группа с обширным и обширным опытом в этом вопросе. Группа - это военные силы по всему миру, которые используют UTC (GMT).

Еще одна вещь, чтобы рассмотреть. Если эти системы поддерживают код приложения, вы должны знать, поддерживают ли приложения часовой пояс. На некоторых форумах по программированию, в которых я участвую, я предлагаю, чтобы дата / время всегда сохранялись в базе данных в формате UTC, и предоставляю конечному пользователю возможность увидеть дату / время.

dbasnett
источник
2

Я работаю в очень крупной хостинговой компании, и у нас есть центры обработки данных по всему миру. Обычно мы устанавливаем время машины в локальное время центра обработки данных, а затем используем часовой пояс, в котором находится весь наш персонал поддержки, в качестве универсального времени, в которое происходит преобразование при использовании инструментов и т. Д.

Как уже говорили другие, нет правильного ответа, но это метод, который мы используем :)

Феб
источник
1

Политика здесь гласит, что все машины привязаны к местному часовому поясу (то есть физическому местоположению). Хитрость только в том, чтобы соотносить записи в журнале событий (windows machiens), поскольку время задает nlocal - большинство других файлов журналов в любом случае записывают время в UTC.

но для пользователей Windows, которые RDesktop в сервер (по любой причине), они застряли с просмотром UTC?

Не совсем уверен, но я думаю, что да - часовой пояс логически является настройкой уровня машины.

TomTom
источник
1

У нас есть машины, физически расположенные в одном часовом поясе, которые настроены на 3 часа вперед из-за приложения, которое они поддерживают.

У нас также есть разработчики, которые создают программное обеспечение, ожидающее синхронизации между серверами менее пяти секунд, разработчики, которые неявно полагаются на время AD для синхронизации, и которые не удосуживаются написать процедуры проверки ошибок или обработки процедур для несинхронизированных случаев, и которые утверждают что последующие сбои - это вина администраторов за то, что они не поддерживали сетевое время на уровне, который они представляли.

Не делай то, что мы сделали. Это просто сделает вас горьким.

AndyN
источник
1

Просто, чтобы добавить к обсуждению, у нас есть офисы, разбросанные по всему миру, и у каждого из них есть свой собственный набор веб-серверов, серверов приложений и баз данных, с различными ветвями приложений для каждого из них, так что местный часовой пояс - хорошая идея, в то время как говорить по всей стране. Что касается серверов США, мы идем к центральному времени, чтобы все местоположения соответствовали нашему основному центру обработки данных, поскольку использование разных часовых поясов для серверов приложений и баз данных затрудняет разработку.

bahrt
источник
0

Приложение Yeller недавно опубликовало сообщение в блоге, в котором всем системным администраторам рекомендуется использовать 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. Use UTC.

Помимо шуток, в основном говорится, что использование только UTC означает не беспокоиться о переходе на летнее время (DST) и об ошибках, которые это вызывает.

dayuloli
источник