Máy Hyper-V làm trôi thời gian khắp nơi, ngay cả với NTP


10

Đã giải quyết vấn đề là Hyper-V trên máy đó. Tôi đã gỡ bỏ Hyper-V, cài đặt VMware Server, chạy cùng một VM. Các vấn đề đồng bộ hóa thời gian đã biến mất (chênh lệch <100ms sau một ngày).


Thiết lập của tôi là như thế này:

HYV1 - HyperV machine (non domain) - sync irrelevant
AD1  - VM AD server on HYV1, sync'd to time.nist.gov. HyperV time sync off.
S1   - Physical machine, sync'd to domain. 
S2   - Physical machine running HyperV, sync'd to domain.
V1   - Linux VM machine on S2, sync'd to AD1. No HyperV integration.

AD1 và S1 có sự đồng bộ tốt - biểu đồ dải hiển thị chênh lệch dưới 100ms.

S2 trôi như điên. Đây là một chút của thoát y so với AD1:

18:33:22 d:+00.0010138s o:+05.4101899s 
18:33:24 d:+00.0010138s o:+05.4319765s 
18:33:26 d:+00.0000000s o:+05.4788429s 
18:33:28 d:+00.0000000s o:+05.6089942s 
18:33:30 d:+00.0010138s o:+05.7240269s 
18:33:32 d:+00.0000000s o:+06.0421911s 
18:33:34 d:+00.0081104s o:+06.5613708s 
18:33:37 d:+00.0000000s o:+06.9096594s 
18:33:39 d:+00.0000000s o:+06.8867838s 
18:33:41 d:+00.0010127s o:+06.8936401s 

Trong 20 giây, nó trôi qua một giây. Nếu tôi tự đặt lại nó trong vòng 1 giây, trong vài phút, nó sẽ trôi trở lại khoảng 2 giây. Qua đêm nó đã đi từ ~ 2 giây đến ~ 5s. Máy ảo Linux bên trong S2 có đồng bộ hóa hoàn hảo với AD1.

Đây là cấu hình:

C:\Users\mgg>w32tm /dumpreg /subkey:Parameters

Value Name                 Value Type          Value Data
------------------------------------------------------------

ServiceDll                 REG_EXPAND_SZ       %systemroot%\system32\w32time.dll
ServiceMain                REG_SZ              SvchostEntry_W32Time
ServiceDllUnloadOnStop     REG_DWORD           1
Type                       REG_SZ              NT5DS
NtpServer                  REG_SZ              ad01.mydomain ad02.mydomain


C:\Users\mgg>w32tm /dumpreg /subkey:Config

Value Name                Value Type          Value Data
-----------------------------------------------------------

FrequencyCorrectRate      REG_DWORD           4
PollAdjustFactor          REG_DWORD           5
LargePhaseOffset          REG_DWORD           50000000
SpikeWatchPeriod          REG_DWORD           900
LocalClockDispersion      REG_DWORD           9
HoldPeriod                REG_DWORD           5
PhaseCorrectRate          REG_DWORD           1
UpdateInterval            REG_DWORD           30000
EventLogFlags             REG_DWORD           2
AnnounceFlags             REG_DWORD           5
TimeJumpAuditOffset       REG_DWORD           28800
MinPollInterval           REG_DWORD           2
MaxPollInterval           REG_DWORD           8
MaxNegPhaseCorrection     REG_DWORD           -1
MaxPosPhaseCorrection     REG_DWORD           -1
MaxAllowedPhaseOffset     REG_DWORD           300

Tôi đã xem nhật ký sự kiện và ngoài các cảnh báo về đồng bộ hóa (sau khi nó không đồng bộ hóa), không có cảnh báo nào khác.

Làm thế nào tôi có thể đi về khắc phục sự cố này? Đây là máy duy nhất gặp vấn đề này. Tất cả các máy khác (vật lý và ảo) đang hoạt động tốt.

Chỉnh sửa: Để làm rõ: VM (AD1) đã tắt tích hợp và đồng bộ hóa với time.nist.gov. AD1 vẫn ổn. Đó là máy vật lý S1 không thể đồng bộ hóa với AD1 và trôi đi khắp nơi. Tất cả các máy chủ vật lý khác có thể đồng bộ hóa với AD1 tốt.

Cập nhật Vì vậy, nó dường như là một vấn đề của việc chạy VM. Đồng hồ trượt chậm với VM tắt. Bật, nó ngay lập tức bắt đầu mất vài giây. Tôi đã sử dụng VM chỉ sử dụng một nửa tài nguyên và hiện tại điều đó dường như đã giảm nhẹ nó. Cảm ơn!

Câu trả lời:


5

Từ mô tả của bạn, có vẻ như có sự cố phần cứng thực tế với RTC ( http://en.wikipedia.org/wiki/Real-time_clock ) trên bo mạch chủ của máy chủ S2.

Khách Hyper-V nhận được đồng hồ ban đầu từ máy chủ (HYV1), nhưng khi bạn tắt đồng bộ hóa thời gian Hyper-V, nó sẽ nhận được tất cả các cập nhật đồng hồ tiếp theo từ NIST (hoạt động tốt). Máy ảo Linux của bạn không được tích hợp với Hyper-V, do đó, nó đang nhận được thời gian từ miền, nó cũng hoạt động tốt. Các máy vật lý khác của bạn đang hoạt động tốt, nó chỉ là một máy chủ vật lý duy nhất có 1 giây trôi sau mỗi 20 giây (đó là một lượng trôi dạt điên cuồng). Thời gian trôi nhanh hơn nhiều so với đồng bộ hóa thời gian mạng có thể đặt lại đồng hồ về đúng thời gian (nếu tôi nhớ lại chính xác diễn ra cứ sau 8 giờ).

Nếu bạn muốn loại trừ Hyper-V là nguyên nhân gây ra lỗi trên S2, hãy tạo một mục khởi động "không Hypervisor", khởi động lại mà không có Hyper-V và xem liệu thời gian trôi có còn không. Hướng dẫn tại đây: http://bloss.msdn.com/virtual_pc_guy/archive/2008/04/14/creating-a-no-hypervisor-boot-entry.aspx

-Sean


OK tôi sẽ thử nó.
MichaelGG

OK, tôi tắt VM (không tắt HyperV). Đồng hồ bây giờ tốt hơn nhiều. Sau khoảng 3 phút, nó chỉ mất khoảng 100ms. Nó vẫn thua, nhưng ít hơn nhiều so với trước đây. Ngay khi tôi bật VM, nó sẽ hoạt động. Nó kist 1 giây trong vài giây. Có lẽ vì VM không có dịch vụ tích hợp?
MichaelGG

Michael- Điều này có vẻ nằm ngoài trường bên trái ở đây, nhưng bạn có đang chạy bất kỳ loại ứng dụng đa phương tiện nào trên phân vùng chính của S2 không? -Sean
Sean Earp

Không. Vấn đề kết thúc là Hyper-V. Đã tắt Hyper-V, đưa vào Vmware Server, chạy cùng một VM - không có vấn đề gì. Đồng bộ hóa thời gian là <100ms.
MichaelGG

3

Vấn đề là với việc triển khai ảo các nguồn đồng hồ khác nhau (tsc, jiffies, acpi_pm, cmos_trc). Cách tốt nhất mà tôi đã tìm thấy để khắc phục sự cố này với HyperV là tắt đồng bộ hóa HyperV được cung cấp cho máy khách của bạn, sau đó sử dụng adjtimex để điều chỉnh thời gian. Trên hệ điều hành khách Ubuntu, hãy làm điều này ...

# rm /var/log/clocks.log
# /etc/init.d/ntp-server stop
# ntpdate ntp.ubuntu.com
# hwclock -u --systohc
# adjtimex -l -u -h ntp.ubuntu.com

và trả lời Không cho cả hai câu hỏi

# while [ /bin/true ] ; do yes | adjtimex -l -u -h ntp.ubuntu.com ; sleep 60 ; done

để nó chạy trong vài giờ để hiệu chỉnh, nhấn Ctrl-C để thoát nó.

# adjtimex -r -a -u -h ntp.ubuntu.com

điều này sẽ làm một phân tích bình phương tối thiểu của đồng hồ của bạn và sẽ tìm thấy sự điều chỉnh phù hợp

# ntpdate ntp.ubuntu.com
# hwclock -u --systohc
# /etc/init.d/ntp-server start

điều này sẽ đồng bộ lại thời gian trên máy của bạn và sau đó ntp sẽ có thể giữ đồng bộ hóa vì nó không bị trôi quá nhiều nữa.


2

Đây dường như là một vấn đề rất phổ biến với VM. Xem các trang web sau:

http://www.vmwareinfo.com/2008/04/eneac-ntp-on-esx-servers.html

http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/6fff3eef-1b5b-4059-8618-22ab3f5c293c

Đề xuất của tôi sẽ là đồng bộ hóa với chỉ một máy chủ thời gian bên ngoài và vô hiệu hóa mọi đồng bộ hóa thời gian tích hợp

Hy vọng điều này sẽ giúp.


Đó chính xác là những gì tôi đã làm. VM (AD1) đã tắt tích hợp và đồng bộ hóa với time.nist.gov. AD1 vẫn ổn. Đó là máy vật lý S1 mất đồng bộ hóa với AD1.
MichaelGG

Giống như chap này nói - để đặt Max ALLowedPhase Offerset thành
gbjbaanb

2

Chúng tôi đã chạy Hyper-v trên Core được một thời gian. Lúc đầu, chúng tôi có vấn đề đồng bộ hóa thời gian ..... Tôi trở lại với một thực tiễn tốt nhất từ ​​các cửa sổ cũ NT của tôi.

Tôi nhìn vào các máy chủ của hệ điều hành. Tôi tạo một Linux, Router, Windows, Novell master.

Bạn có thể không có Novell bây giờ nhưng chịu đựng tôi.

Mỗi máy chủ "chính" đồng bộ với bộ định tuyến. Các bộ định tuyến đến tầng. Sau đó, mỗi máy chủ thành viên có máy chủ hệ điều hành chính và một máy chủ phụ của một trong các Master khác.

  • Linux sang Router, sau đó đến Novell
  • Novell to Router, sau đó đến Windows
  • Windows sang bộ định tuyến, sau đó đến Linux
  • Bộ định tuyến đến Stratum, sau đó chuyển sang Core
  • Core Switch sang Stratum, sau đó đến Router

Phần cuối cùng của chiến lược này là ... MỌI THỨ có một máy chủ thời gian. Nếu nó không có máy chủ thời gian thì nó sẽ không được cắm vào mạng. Từ máy nướng bánh mì để chuyển sang tổng đài điện thoại đến máy chủ.

Đây là một trong những điều đầu tiên tôi làm khi đến một công việc mới là dành thời gian để lập bản đồ mạng và đặt thời gian. Sau đó tôi có thể kiểm tra nó ở đây và ở đó và loại bỏ đồng bộ hóa thời gian là một vấn đề kể từ thời điểm đó.


Hmm, tôi sẽ thử thêm một thứ cấp thủ công và xem nếu nó giúp. Nhưng mọi thứ khác đều hoạt động tốt - chỉ một chiếc máy vật lý này trôi đi.
MichaelGG

Đó là loại máy gì? Dell / HP / IBM - Khác? Tôi đã có các hộp Dell mà luôn luôn cần phải điều chỉnh.
Thomas Denton

Dell PowerEdge 850 với Pentium D920 trong đó (hoặc một cái gì đó xung quanh - 2,8 GHz, Intel VT.)
MichaelGG

PE 350 sẽ trôi dạt rất tệ. nhưng nó đã từ nhiều năm trước. Tôi chưa sử dụng 850 nhưng các máy chủ SC1435 tương tự rẻ hơn so với 850 hoạt động tốt. Có thể nhìn vào môi trường, máy chủ có rung và pin cmos bị lỏng hay có thứ gì đó điên rồ như vậy không?
Thomas Denton

1

Thời gian trôi đi khắp nơi trong VM. Bạn thực sự muốn đảm bảo rằng máy chủ NTP không sử dụng đồng hồ cục bộ trong bất kỳ câu lệnh 'máy chủ' nào, vì đồng hồ cục bộ quá không đáng tin cậy. Một điều tôi đã làm để giúp đỡ là đặt thuộc tính "maxpoll" cho các máy chủ trên các máy ảo. Điều này buộc dịch vụ ntp phải kiểm tra với các đồng hồ ngược dòng của nó thường xuyên hơn nhiều so với mặc định được cấu hình, giúp giữ đúng.

server [timeserver] maxpoll 12

Hãy thử một vài cài đặt để xem bạn cần đi bao xa để giữ thời gian tương đối đáng tin cậy. 12 công việc cho tôi, nhưng mỗi môi trường là khác nhau.


Tôi đã thử với thời gian bình chọn là 2 hoặc 4 (16 giây). Vẫn trôi dạt điên cuồng.
MichaelGG

1

Điều này nghe có vẻ buồn cười, nhưng tôi cá là bạn đang chạy một thiết lập đa bộ xử lý? Có biết đến vấn đề đồng hồ trôi dạt với các nhà sản xuất nào đó ho AMD ho điều đó xảy ra với bo mạch chủ đa lõi / đa socket. Hoạt động gián đoạn nặng nề - như nói, chạy một hoặc hai máy ảo - làm cho tình trạng trôi dạt tồi tệ hơn. Các trôi bạn đang gặp những âm thanh rất nghi ngờ như thế này.

Đối với những gì đáng giá, tôi thích các dịch vụ của AMD hơn Intel, vì vậy đừng coi đây là một cú hích đối với họ.


Máy đang chạy Pentium D930, vì vậy nó là một thiết lập đa lõi. Tôi sẽ vô hiệu hóa VM và xem điều gì sẽ xảy ra.
MichaelGG

2
Giết một lõi trên VM đã giúp đồng bộ hóa trên máy chủ.
MichaelGG

1

Giả sử rằng AD1 là bộ điều khiển miền, tôi nghĩ rằng vấn đề ở đây có thể liên quan đến máy chủ Hyper-V của bạn đặt thời gian từ một trong những máy khách của chính nó. Đó là lý do tại sao vấn đề biến mất khi bạn chuyển sang VMware: máy chủ VMware không cảm thấy bắt buộc phải đồng bộ hóa đồng hồ của nó với bộ điều khiển miền Windows.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.