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

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

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

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

22
задан 15 October 2010 в 15:50
8 ответов

Как с большинством вещей, "это зависит".

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

Я сделал все опции (Локальный, UTC, произвольный но последовательный), и предпочитаю "местное время домашнему офису для всех машин", как это - то, где системные администраторы и пользователи были, даже при том, что машины были рассеяны во всем мире.

19
ответ дан 2 December 2019 в 20:00

Мы устанавливаем все на GMT, он делает файлы журнала корреляции через системы более простыми.

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

6
ответ дан 2 December 2019 в 20:00

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

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

3
ответ дан 2 December 2019 в 20:00

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

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

2
ответ дан 2 December 2019 в 20:00

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

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

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

1
ответ дан 2 December 2019 в 20:00

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

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

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

1
ответ дан 2 December 2019 в 20:00

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

1
ответ дан 2 December 2019 в 20:00

Yeller App недавно опубликовал запись в блоге , в которой советовал всем сисадминам использовать 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), а также об ошибках, которые это приводит к.

.
0
ответ дан 2 December 2019 в 20:00

Теги

Похожие вопросы