ฉันมีเซิร์ฟเวอร์ 3 เครื่องที่ใช้ CentOS 7.9.2009 ในศูนย์ข้อมูล (VMware ESXi) เซิร์ฟเวอร์เหล่านี้รายงานว่าเวลาไม่ตรงกัน ฉันมีสภาพแวดล้อมการทดสอบที่คล้ายกันซึ่งทำงานบนเซิร์ฟเวอร์ VMware ESXi ภายในที่ซึ่งเซิร์ฟเวอร์ซิงค์ เวลาตกลงเดิมทีสภาพแวดล้อมการใช้งานจริงได้รับการตั้งค่าในลักษณะเดียวกันทุกประการ แต่เห็นได้ชัดว่ามีการปรับปรุงด้วยการอัปเดตแพ็คเกจเมื่อเวลาผ่านไป ดังนั้นพวกเขา "ควร" เหมือนกัน - แต่ฉันไม่สามารถรับประกันได้อีกต่อไป เซิร์ฟเวอร์ ESXi เป็นทั้งเวอร์ชัน 6
เดิมเซิร์ฟเวอร์ได้รับการกำหนดค่าโดยใช้ "ntpd" - แต่เมื่อแก้ไขปัญหานี้ในช่วงสองสามวันที่ผ่านมา ฉันพบว่า "Chrony" ดูเหมือนจะเป็นตัวเลือกที่ดีกว่าบน CentOS 7 ฉันจึงได้กำหนดค่าเซิร์ฟเวอร์ใหม่เพื่อใช้ Chrony - แต่ยังคง มีปัญหา
แก้ไข: ขั้นตอนที่ใช้ในการเปลี่ยนเป็น Chrony
ดังนั้นเมื่อฉันใช้ วันที่เวลา ฉันได้รับผลลัพธ์นี้:
เวลาท้องถิ่น: จันทร์ 2021-08-02 09:14:43 CEST
เวลาสากล: จันทร์ 2021-08-02 07:14:43 UTC
เวลา RTC: จันทร์ 2021-08-02 07:16:34 น
โซนเวลา: Europe/Copenhagen (CEST, +0200)
เปิดใช้งาน NTP: ใช่
NTP ซิงโครไนซ์: ไม่
RTC ใน TZ ท้องถิ่น: ไม่
DST ทำงานอยู่: ใช่
การเปลี่ยนแปลง DST ครั้งล่าสุด: DST เริ่มต้นเมื่อ
อา. 2021-03-28 01:59:59 CET
อา. 2021-03-28 03:00:00 CEST
การเปลี่ยนแปลง DST ครั้งต่อไป: DST สิ้นสุด (นาฬิกาเดินถอยหลังหนึ่งชั่วโมง) ที่
อา. 2021-10-31 02:59:59 CEST
อา. 2021-10-31 02:00:00 CET
ถ้าฉันรีสตาร์ท Chrony โดยใช้ systemctl รีสตาร์ท chronyd หลังจากนั้นสองสามวินาที วันที่เวลา รายงาน:
เวลาท้องถิ่น: จันทร์ 2021-08-02 09:26:06 CEST
เวลาสากล: จันทร์ 2021-08-02 07:26:06 UTC
เวลา RTC: จันทร์ 2021-08-02 07:26:08 น
โซนเวลา: Europe/Copenhagen (CEST, +0200)
เปิดใช้งาน NTP: ใช่
ซิงโครไนซ์ NTP: ใช่
RTC ใน TZ ท้องถิ่น: ไม่
DST ทำงานอยู่: ใช่
การเปลี่ยนแปลง DST ครั้งล่าสุด: DST เริ่มต้นเมื่อ
อา. 2021-03-28 01:59:59 CET
อา. 2021-03-28 03:00:00 CEST
การเปลี่ยนแปลง DST ครั้งต่อไป: DST สิ้นสุด (นาฬิกาเดินถอยหลังหนึ่งชั่วโมง) ที่
อา. 2021-10-31 02:59:59 CEST
อา. 2021-10-31 02:00:00 CET
หลังจากนั้นสักครู่ (นาที) ก็จะกลับไปที่ NTP ซิงโครไนซ์: ไม่.
เมื่อฉันวิ่ง ntpstat ฉันเข้าใจ:
ซิงโครไนซ์กับเซิร์ฟเวอร์ NTP (217.198.219.102) ที่ชั้น 2
แก้ไขเวลาเป็นภายใน 124123 ms
เซิร์ฟเวอร์การสำรวจทุกๆ 64 วินาที
หรือ
ไม่ซิงโครไนซ์
ไม่ทราบช่วงเวลาการสำรวจความคิดเห็น
ในกรณีสุดท้ายหลังจากนั้นสักครู่จะแสดงผลลัพธ์แรกอีกครั้ง แต่ "ภายใน ... มิลลิวินาที" ดูค่อนข้างสูง???
เนื่องจากฉันสามารถซิงโครไนซ์ได้โดยการรีสตาร์ท Chrony ฉันจึงเดาว่าไฟร์วอลล์/เครือข่ายนั้นใช้ได้ ฉันใช้การกำหนดค่าเริ่มต้นของ Chrony (เหมือนที่ฉันเคยทำกับ ntpd มาก่อน)
ติดตั้งและเริ่มบริการ VMwaretools (open-vm-tools, http://github.com/vmware/open-vm-tools).
ฉันขอขอบคุณคำแนะนำสำหรับการแก้ไขปัญหานี้เพิ่มเติม - และแก้ไขในที่สุด ;-)
ขอบคุณล่วงหน้า!
/จอห์น
ฉันคิดว่าฉันได้แก้ไขแล้ว
โดยพื้นฐานแล้ว พงศาวดารคิดว่าเวลาผันแปรมากเกินไป ดังนั้นตามลิงค์ของ Peter Rosenberg (และแหล่งข้อมูลที่ลิงค์ไป) ฉันจึงไปตามทาง ....
ฉันได้ใส่ข้อมูลนี้ไว้ที่นี่เผื่อว่าจะมีคนอื่นค้นหาข้อมูลนี้
ขั้นตอนแรกในกระบวนการคือสถานะจากบริการ chronyd:
สถานะ systemctl chronyd
â chronyd.service - ไคลเอ็นต์/เซิร์ฟเวอร์ NTP
โหลดแล้ว: โหลดแล้ว (/usr/lib/systemd/system/chronyd.service; เปิดใช้งาน; การตั้งค่าล่วงหน้าของผู้ขาย: เปิดใช้งาน)
ใช้งานอยู่: ใช้งานอยู่ (ทำงาน) ตั้งแต่วันจันทร์ที่ 2021-08-02 22:23:39 CEST; 10 ชั่วโมงที่แล้ว
เอกสาร: man:chronyd(8)
ชาย:chrony.conf(5)
กระบวนการ: 24758 ExecStartPost=/usr/libexec/chrony-helper update-daemon (รหัส=ออก, สถานะ=0/สำเร็จ)
กระบวนการ: 24754 ExecStart=/usr/sbin/chronyd $OPTIONS (รหัส=ออก, สถานะ=0/สำเร็จ)
PID หลัก: 24756 (chronyd)
CGroup: /system.slice/chronyd.service
ââ24756 /usr/sbin/chronyd
03 ส.ค. 08:41:24 db1.aqua.dtu.dk chronyd[24756]: แหล่งที่เลือก 162.159.200.1
03 ส.ค. 08:41:24 db1.aqua.dtu.dk chronyd[24756]: นาฬิการะบบผิด 5.118732 วินาที เริ่มการปรับ
03 ส.ค. 08:41:26 db1.aqua.dtu.dk chronyd[24756]: ไม่สามารถซิงโครไนซ์: ไม่มีเสียงข้างมาก
03 ส.ค. 08:41:33 db1.aqua.dtu.dk chronyd[24756]: แหล่งที่เลือก 162.159.200.123
03 ส.ค. 08:41:33 db1.aqua.dtu.dk chronyd[24756]: นาฬิการะบบผิด 1.761045 วินาที เริ่มการปรับ
03 ส.ค. 08:42:29 น. db1.aqua.dtu.dk chronyd[24756]: ไม่สามารถซิงโครไนซ์ได้: ไม่มีเสียงข้างมาก
3 ส.ค. 08:42:30 น. db1.aqua.dtu.dk chronyd[24756]: แหล่งที่เลือก 192.36.143.130
03 ส.ค. 08:42:30 db1.aqua.dtu.dk chronyd[24756]: นาฬิการะบบผิด 4.500188 วินาที เริ่มการปรับ
03 ส.ค. 08:43:34 db1.aqua.dtu.dk chronyd[24756]: นาฬิการะบบผิด 4.842190 วินาที เริ่มการปรับ
3 ส.ค. 08:44:39 น. db1.aqua.dtu.dk chronyd[24756]: ไม่สามารถซิงโครไนซ์ได้: ไม่มีแหล่งที่มาที่เลือกได้
เห็นได้ชัดว่ามีบางอย่างผิดปกติ ดังนั้นขั้นตอนต่อไปคือ:
chronyc แหล่ง -v
210 จำนวนแหล่งที่มา = 4
.-- โหมดซอร์ส '^' = เซิร์ฟเวอร์, '=' = เพียร์, '#' = นาฬิกาในเครื่อง
/ .- สถานะต้นทาง '*' = ปัจจุบันซิงค์, '+' = รวม , '-' = ไม่รวม
| / '?' = ไม่สามารถเข้าถึงได้ 'x' = เวลาอาจคลาดเคลื่อน '~' = เวลาผันแปรเกินไป
|| .- xxxx [ yyyy ] +/- zzzz
|| การลงทะเบียนการเข้าถึง (ฐานแปด) -. | xxxx = ออฟเซ็ตที่ปรับแล้ว
|| Log2 (ช่วงเวลาการสำรวจ) --. | | ปปปป = ค่าชดเชยที่วัดได้
|| \ | | zzzz = ข้อผิดพลาดโดยประมาณ
|| | | \
ชื่อ MS/ที่อยู่ IP Stratum Poll ถึง LastRx ตัวอย่างสุดท้าย
================================================== =============================
^~ time.cloudflare.com 3 6 377 1 -17.0s[ -17.0s] +/- 1318us
^~ Time100.Stupi.SE 1 6 377 2 -16.9 วินาที[ -16.9 วินาที] +/- 4458 วินาที
^~ time.cloudflare.com 3 6 377 53 -11.2 วินาที[ -11.2 วินาที] +/- 1306 วินาที
^~ n1.taur.dk 1 6 377 60 -10.4s[ -10.4s] +/- 4964us
แจ้งให้ทราบ เวลาผันแปรเกินไป สำหรับทุกเซิร์ฟเวอร์....
และ การติดตามแบบเรื้อรัง ยังแสดงว่าเวลาไม่ตรงกันเลย:
รหัสอ้างอิง : C0248F82 (Time100.Stupi.SE)
ชั้น : 2
Ref time (UTC) : อ. 03 ส.ค. 06:46:05 2021
เวลาของระบบ : ช้ากว่าเวลา NTP 132.970306396 วินาที
ออฟเซ็ตล่าสุด : -4.842189789 วินาที
RMS offset : 7.720179081 วินาที
ความถี่ : 63.104 ppm ช้า
ความถี่ตกค้าง : -81143.852 ppm
ความเบ้ : 90.130 ppm
ความล่าช้าในการรูท: 0.008654756 วินาที
การกระจายรูต : 19.424978256 วินาที
ช่วงเวลาการอัพเดท : 58.2 วินาที
สถานะการกระโดด : ปกติ
หลังจากอ่านเพิ่มเติมในการอ้างอิงถึงบทความที่กล่าวถึง ฉันพยายามปรับ ทำขั้นตอน ใน /etc/chrony.conf ไฟล์เพื่อบังคับให้อัปเดต ฉันได้เปลี่ยนเซิร์ฟเวอร์พูล NTP เป็น "ใกล้" เซิร์ฟเวอร์แอปพลิเคชันแล้ว ดังนั้นไฟล์กำหนดค่าจึงมีลักษณะดังนี้:
เซิร์ฟเวอร์ 0.dk.pool.ntp.org ระเบิด
เซิร์ฟเวอร์ 1.dk.pool.ntp.org ระเบิด
เซิร์ฟเวอร์ 2.dk.pool.ntp.org ระเบิด
เซิร์ฟเวอร์ 3.dk.pool.ntp.org ระเบิด
Driftfile /var/lib/chrony/drift.drift
ทำขั้นตอนที่ 1 -1
rtcsync
ตอนนี้ทำงานมาระยะหนึ่งแล้วและดูเหมือนว่าจะรักษาเวลาให้ตรงกัน ;-)
แก้ไข:
ดังที่ Paul Gear ชี้ให้เห็น ฉันไม่ได้แก้ไขปัญหานี้ ... เวลายังคงเลื่อนลอย
โดยใช้ /usr/bin/vmware-toolbox-cmd สถานะ timesync ฉันพบว่าการซิงโครไนซ์เวลาบนเซิร์ฟเวอร์ที่ใช้งานจริงกับโฮสต์ ESXi ถูกเปิดใช้งาน (!!!) ฉันไม่รู้ว่าสิ่งนี้เกิดขึ้นได้อย่างไร? VM เดิมที่ฉันกำหนดค่าและอัปโหลดไปยังศูนย์ข้อมูลไม่ได้เปิดใช้งานเห็นได้ชัดว่าไม่ควรซิงค์ด้วยวิธีใด เวลาอยู่กับโฮสต์
ค่อนข้างง่ายที่จะปิดการใช้งานโดยใช้: /usr/bin/vmware-toolbox-cmd timesync ปิดใช้งาน
และตอนนี้เรามีข้อมูลที่เป็นจริงมากขึ้นจาก chronyc แหล่ง -v:
210 จำนวนแหล่งที่มา = 4
.-- โหมดซอร์ส '^' = เซิร์ฟเวอร์, '=' = เพียร์, '#' = นาฬิกาในเครื่อง
/ .- สถานะต้นทาง '*' = ปัจจุบันซิงค์, '+' = รวม , '-' = ไม่รวม
| / '?' = ไม่สามารถเข้าถึงได้ 'x' = เวลาอาจคลาดเคลื่อน '~' = เวลาผันแปรเกินไป
|| .- xxxx [ yyyy ] +/- zzzz
|| การลงทะเบียนการเข้าถึง (ฐานแปด) -. | xxxx = ออฟเซ็ตที่ปรับแล้ว
|| Log2 (ช่วงเวลาการสำรวจ) --. | | ปปปป = ค่าชดเชยที่วัดได้
|| \ | | zzzz = ข้อผิดพลาดโดยประมาณ
|| | | \
ชื่อ MS/ที่อยู่ IP Stratum Poll ถึง LastRx ตัวอย่างสุดท้าย
================================================== =============================
^- sweetums.eng.tdc.net 2 7 377 36 +30us[ +30us] +/- 45ms
^* 77.68.139.83 1 7 377 92 -191us[ -184us] +/- 4742us
^- 152.115.59.244 2 7 377 39 +99us[ +99us] +/- 31ms
^- pf.safe-con.dk 2 7 377 42 +359us[ +359us] +/- 29ms
เช่นเดียวกับ การติดตามแบบเรื้อรัง:
รหัสอ้างอิง : 4D448B53 (77.68.139.83)
ชั้น : 2
Ref time (UTC) : อ. 03 ส.ค. 10:45:26 2021
เวลาของระบบ : ช้ากว่าเวลา NTP 0.000008465 วินาที
ออฟเซ็ตล่าสุด : +0.000006720 วินาที
RMS offset : 7.358564854 วินาที
ความถี่ : ช้า 57.633 ppm
ความถี่ตกค้าง : +0.001 ppm
ความเบ้ : 0.340 ppm
ความล่าช้าในการรูท: 0.009058274 วินาที
การกระจายตัวของรูต : 0.000351956 วินาที
ช่วงเวลาการอัพเดท : 128.8 วินาที
สถานะการกระโดด : ปกติ
ตอนนี้มันทำงานได้อย่างราบรื่นมาครึ่งชั่วโมงแล้ว ดังนั้นฉันจึงมั่นใจว่านี่คือวิธีแก้ปัญหา ขอบคุณสำหรับการป้อนข้อมูล !!!
พิจารณาใช้การตั้งค่าไคลเอนต์ขั้นต่ำตามที่แนะนำที่นี่: https://www.golinuxcloud.com/configure-chrony-ntp-server-client-force-sync/ เมื่อถึงเกณฑ์การดริฟท์ มันจะยกเลิกการซิงก์ซึ่งดูเหมือนจะเกิดขึ้นกับคุณ
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
