Казка про втрачений час або mind shift with time drift, konstantin leontiev - s weblog

Давненько я не брав в руки ... шашок.

Як багато можливо здогадуються, я в своїй практиці інфраструктурних проектів постійно стикаюся з різними цікавими і складними речами, але далеко не завжди хочеться про них написати, та й просто часу / сил на все не завжди вистачає. Однак, про даному примітному факт я все ж не можу втриматися і розповім ...

[Далі в цілях конспірації та дотримання норм пристойності всі факти за винятком технічних змінені]

І ось кластер зібраний, СУБД встановлена ​​і почалася дослідно / штатна експлуатація. Всі задоволені і здається все працює. І тут у одного з ваших цікавих інженерів виникає питання - а що це за дивні події від джерела w32time з кодом 50 виникають в журналі ... А події дійсно дивні:

Event ID: 50
Source: W32time
Type: Warning
The time service detected a time difference of greater than 5000 milliseconds for 900 seconds. The time difference might be caused by synchronization with low-accuracy time sources or by suboptimal network conditions. The time service is no longer synchronized and can not provide the time to other clients or update the system clock. When a valid time stamp is received from a time service provider, the time service will correct itself.

І тут ви замислюєтеся, власне а до чого б це? ... пошукавши в Інтернеті і проаналізувавши Microsoft KB і інші джерела ясності не настає. Останні оновлення у вас стоять. І взагалі кластер синхронізується з найближчого PDC, який знаходитися в тій же гигабитной мережі, що і кластер.

Далі ви робите просту здавалося б річ - включаєте порівняння часу на одному з вузлів вашого кластера з яким-небудь контролером домену використовуючи команду:

w32tm / stripchart / computer: / dataonly

і бачите, що всупереч звичайним спостереженнями, коли різниця в часі статистично плаває біля одного постійного значення, середнє значення відхилення у вас змінюється занадто швидко. Що таке занадто швидко - наприклад зі швидкістю більше 2-3 хвилин на добу. Насправді в разі кластера навіть 2-3 хвилини на добу забагато. Чи варто мені пояснювати, що при швидкості близько 15-20 хвилин на добу - ситуація є просто критичною і вимагає негайного вирішення. У моєму випадку були саме такі порядки "витоку" часу (Time Drift).

Ви запитаєте, а які ж наслідки можуть бути при такій високій швидкості витоку? Ну давайте собі їх представимо:

Звичайно, можна піти простим шляхом і просто налаштувати агресивну синхронізацію часу, наприклад так:

Однак, таке тимчасове / обхідний рішення не дає розуміння кореневої причини проблеми і більш того може таїти в собі певні проблеми, які можуть проявитися в майбутньому.

Опис цього ключа і деяких проблем, що вимагають його використання дані тут:

Що ж робити в такій ситуації:

Більш того, ця проблема може досить активно проявлятися при використанні віртуалізації.