เครื่อง Hyper-V ทำให้เวลาผ่านไปอย่างยาวนานแม้กระทั่งกับ NTP

แก้ไข ปัญหาแล้วคือ Hyper-V บนเครื่องนั้น ฉันลบ Hyper-V, ติดตั้งเซิร์ฟเวอร์ VMware, รัน VM เดียวกัน ปัญหาการซิงค์เวลาหายไป (<100ms แตกต่างหลังจากหนึ่งวัน)

การตั้งค่าของฉันเป็นเช่นนี้:

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 และ S1 มีการซิงค์อย่างละเอียด - stripchart แสดงความแตกต่างน้อยกว่า 100ms

S2 ลอยไปอย่างบ้าคลั่ง นี่เป็นส่วนหนึ่งของ stripchart เทียบกับ 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 

ใน 20 วินาทีมันลอยไปในหนึ่งวินาที หากฉันรีเซ็ตด้วยตนเองเป็นภายใน 1 วินาทีภายในไม่กี่นาทีมันจะกลับมาลอยประมาณ 2 วินาที ค้างคืนมันเปลี่ยนจาก ~ 2s เป็น ~ 5s Linux VM ใน S2 มีการซิงค์ที่สมบูรณ์แบบกับ AD1

นี่คือการกำหนดค่า:

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

ฉันดูที่บันทึกเหตุการณ์และนอกเหนือจากคำเตือนเกี่ยวกับการซิงค์ (หลังจากที่ได้รับจากการซิงค์) ไม่มีคำเตือนอื่น ๆ

ฉันจะแก้ไขปัญหานี้ได้อย่างไร เป็นเครื่องเดียวที่ประสบปัญหานี้ เครื่องอื่น ๆ (จริงและเสมือน) กำลังทำงานได้ดี

แก้ไข:เพื่อชี้แจง: VM (AD1) ได้ปิดการรวมและซิงค์กับ time.nist.gov AD1 ใช้ได้ มันเป็นเครื่องกายภาพ S1 ที่ไม่สามารถซิงค์กับ AD1 และลอยไปทั่ว ฟิสิคัลเซิร์ฟเวอร์อื่น ๆ ทั้งหมดสามารถซิงค์กับ AD1 ได้ดี

อัปเดต ดังนั้นดูเหมือนว่าจะมีปัญหาในการใช้งาน VM นาฬิกาลื่นช้าๆโดยปิด VM เปิดใช้งานมันจะเริ่มเสียวินาทีทันที ฉัน swt VM ที่จะใช้เพียงครึ่งเดียวของทรัพยากรและดูเหมือนว่าจะลดลงเล็กน้อยในตอนนี้ ขอบคุณ!

จากคำอธิบายของคุณดูเหมือนว่ามีปัญหาฮาร์ดแวร์จริงกับ RTC ( http://en.wikipedia.org/wiki/Real-time_clock ) บนเมนบอร์ดของเซิร์ฟเวอร์ S2

แขก Hyper-V ทำให้นาฬิกาเป็นโฮสต์จากโฮสต์ (HYV1) แต่เมื่อคุณปิดใช้งานการซิงค์เวลา Hyper-V จะได้รับการอัปเดตนาฬิกาเพิ่มเติมจาก NIST (ซึ่งทำงานได้ดี) Linux VM ของคุณไม่ได้รวมเข้ากับ Hyper-V ดังนั้นจึงได้เวลาจากโดเมนซึ่งทำงานได้ดี เครื่องฟิสิคัลอื่น ๆ ของคุณทำงานได้ดีมันเป็นเพียงเซิร์ฟเวอร์ฟิสิคัลเดียวที่มีการดริฟท์ 1 วินาทีทุก ๆ 20 วินาที (ซึ่งเป็นจำนวนการดริฟท์ที่บ้าคลั่ง) เวลาลอยเร็วกว่าการซิงค์เวลาเครือข่ายสามารถรีเซ็ตนาฬิกาเป็นเวลาที่เหมาะสม (ซึ่งถ้าฉันจำได้ถูกต้องเกิดขึ้นทุก 8 ชั่วโมง)

หากคุณต้องการออกกฎ Hyper-V เป็นสาเหตุของข้อผิดพลาดใน S2 ให้สร้างรายการบูต "no Hypervisor" รีบูตโดยไม่มี Hyper-V และดูว่าเวลายังคงมีอยู่หรือไม่ คำแนะนำได้ที่นี่: http://blogs.msdn.com/virtual_pc_guy/archive/2008/04/14/creating-a-no-hypervisor-boot-entry.aspx

ฌอน

ปัญหาคือการใช้งานจริงของแหล่งสัญญาณนาฬิกาต่างๆ (tsc, jiffies, acpi_pm, cmos_trc) วิธีที่ดีที่สุดที่ฉันได้พบเพื่อแก้ไขปัญหานี้ด้วย HyperV คือการปิด HyperV ที่ให้ไว้สำหรับการซิงก์นาฬิกาของคุณจากนั้นใช้ adjtimex เพื่อปรับเวลา บนระบบปฏิบัติการ Ubuntu แขกทำสิ่งนี้ ...

# 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

และตอบว่าไม่ใช่สำหรับทั้งสองคำถาม

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

ปล่อยให้ดำเนินการปรับเทียบสองสามชั่วโมงกด Ctrl-C เพื่อออก

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

สิ่งนี้จะทำการวิเคราะห์กำลังสองน้อยที่สุดของนาฬิกาของคุณและจะหาการปรับที่เหมาะสม

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

การทำเช่นนี้จะซิงค์เวลาบนเครื่องของคุณและจากนั้น ntp ควรจะสามารถซิงค์ในเวลาเดียวกันได้เพราะมันไม่ควรลอยมากเกินไปอีกต่อไป

นี่น่าจะเป็นปัญหาที่พบได้บ่อยกับ VM ดูเว็บไซต์ต่อไปนี้:

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

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

ข้อเสนอแนะของฉันคือการซิงค์กับเซิร์ฟเวอร์เวลาภายนอกและปิดการซิงค์เวลาการรวมใด ๆ

หวังว่านี่จะช่วยได้

เราใช้ Hyper-v บน Core มาระยะหนึ่งแล้ว ตอนแรกเรามีปัญหาเรื่องการซิงค์เวลา ..... ฉันกลับสู่แนวทางปฏิบัติที่ดีที่สุดจาก windows NT ของฉันวันเก่า

ฉันดูเซิร์ฟเวอร์โดยระบบปฏิบัติการ ฉันสร้าง Linux, Router, Windows, Novell master

คุณอาจไม่ได้รับ Novell ตอนนี้ แต่อดทนกับฉัน

เซิร์ฟเวอร์ "master" แต่ละตัวจะซิงค์กับเราเตอร์ เราเตอร์ถึงชั้น จากนั้นเซิร์ฟเวอร์สมาชิกแต่ละแห่งจะมีเซิร์ฟเวอร์ระบบปฏิบัติการหลักและเซิร์ฟเวอร์รองของหนึ่งในโทอื่น ๆ

• Linux กับเราเตอร์แล้วไปยัง Novell
• Novell to Router จากนั้นเข้าสู่ Windows
• Windows ไปยังเราเตอร์แล้วไปที่ Linux
• เราเตอร์ถึง Stratum จากนั้นไปที่ Core switch
• Core Switch เป็น Stratum จากนั้นเป็น Router

ส่วนสุดท้ายของกลยุทธ์นี้คือ ... ทุกอย่างมีเซิร์ฟเวอร์เวลา หากไม่มีเซิร์ฟเวอร์เวลาจะไม่ถูกเชื่อมต่อกับเครือข่าย จากเครื่องปิ้งขนมปังเพื่อเปลี่ยนเป็นโทรศัพท์ PBX ไปยังเซิร์ฟเวอร์

นี่เป็นหนึ่งในสิ่งแรกที่ฉันทำเมื่อฉันได้งานใหม่คือใช้เวลาในการแมปเครือข่ายและตั้งเวลา ฉันสามารถตรวจสอบได้ที่นี่และมีและกำจัดเวลาซิงค์เป็นปัญหาจากจุดนั้น

เวลาลอยทั่วสถานที่ใน VMs คุณต้องการตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ NTP ไม่ได้ใช้นาฬิกาในเครื่องในคำสั่ง 'เซิร์ฟเวอร์' ใด ๆ เนื่องจากนาฬิกาในเครื่องไม่น่าเชื่อถือเกินไป สิ่งหนึ่งที่ฉันทำเพื่อช่วยคือการตั้งค่าแอตทริบิวต์ "maxpoll" สำหรับเซิร์ฟเวอร์บนเครื่อง VMed สิ่งนี้บังคับให้บริการ ntp ตรวจสอบกับนาฬิกา upstream บ่อยกว่าค่าเริ่มต้นที่กำหนดไว้ซึ่งช่วยให้เป็นจริง

server [timeserver] maxpoll 12

ลองตั้งค่าบางอย่างเพื่อดูว่าคุณต้องใช้เวลามากน้อยเพียงใดในการทำให้เวลาเชื่อถือได้ 12 ใช้ได้กับฉัน แต่แต่ละสภาพแวดล้อมนั้นแตกต่างกัน

อาจฟังดูตลก แต่ฉันคิดว่าคุณกำลังใช้การตั้งค่ามัลติโปรเซสเซอร์? มีปัญหาที่ทราบนาฬิกาดริฟท์กับผู้ผลิตบาง ไอเอเอ็มดีไอที่เกิดขึ้นกับเมนบอร์ดแบบ multi-core / หลายซ็อกเก็ต การขัดจังหวะอย่างหนักเช่นการเรียกใช้งานเครื่องเสมือนหรือสองเครื่องทำให้การดริฟท์แย่ลง เสียงดริฟท์ที่คุณกำลังฟังดูเหมือนน่าสงสัยอย่างนี้

สำหรับสิ่งที่คุ้มค่าฉันจะชอบข้อเสนอของ AMD มากกว่า Intel ดังนั้นอย่าเอาสิ่งนี้มาทำสิ่งที่ผิดพลาด

สมมติว่า AD1 เป็นตัวควบคุมโดเมนฉันคิดว่าปัญหาที่นี่อาจเกี่ยวข้องกับเซิร์ฟเวอร์ Hyper-V ของคุณในการตั้งค่าเวลาจากหนึ่งใน VM ที่เป็นแขกของตัวเอง นั่นเป็นสาเหตุว่าทำไมปัญหาหายไปเมื่อคุณเปลี่ยนเป็น VMware: เซิร์ฟเวอร์ VMware ไม่รู้สึกว่าถูกบังคับให้ซิงโครไนซ์นาฬิกากับตัวควบคุมโดเมน Windows