ฉันได้อ่านหลาย ๆ ครั้ง (แม้ว่าฉันจะหาไม่ได้ในตอนนี้) ที่ศูนย์ข้อมูลใช้ความพยายามอย่างมากเพื่อให้แน่ใจว่าเซิร์ฟเวอร์ทั้งหมดมีเวลาที่แน่นอน รวมถึง แต่ไม่ จำกัด เพียงการกังวลเกี่ยวกับการกระโดดวินาที
เหตุใดจึงสำคัญที่เซิร์ฟเวอร์มีเวลาเดียวกัน และความคลาดเคลื่อนที่แท้จริงคืออะไร
คำตอบ:
โดยทั่วไปแล้วการประทับเวลาจะใช้ในโปรโตคอลการตรวจสอบความถูกต้องต่างๆเพื่อช่วยป้องกันการโจมตีซ้ำซึ่งผู้โจมตีสามารถนำโทเค็นการตรวจสอบสิทธิ์มาใช้ซ้ำซึ่งเขาสามารถขโมยได้ (เช่นโดยการดมเครือข่าย)
การพิสูจน์ตัวตน Kerberos ทำสิ่งนี้อย่างแน่นอนตัวอย่างเช่น ในเวอร์ชันของ Kerberos ที่ใช้ใน Windows ค่าเผื่อเริ่มต้นคือ 5 นาที
นอกจากนี้ยังใช้โดยโปรโตคอลรหัสผ่านแบบใช้ครั้งเดียวหลายครั้งที่ใช้สำหรับการตรวจสอบสิทธิ์แบบสองปัจจัยเช่น Google Authenticator, RSA SecurID เป็นต้นในกรณีเหล่านี้ความอดทนมักจะอยู่ที่ประมาณ 30-60 วินาที
หากไม่มีเวลาที่ซิงค์ระหว่างไคลเอนต์และเซิร์ฟเวอร์จะไม่สามารถทำการตรวจสอบสิทธิ์ให้เสร็จสิ้นได้ (ข้อ จำกัด นี้จะถูกลบออกใน MIT Kerberos รุ่นใหม่ล่าสุดโดยให้ผู้ร้องขอและ KDC กำหนดออฟเซ็ตระหว่างนาฬิกาในระหว่างการตรวจสอบสิทธิ์ แต่การเปลี่ยนแปลงเหล่านี้เกิดขึ้นหลังจาก Windows Server 2012 R2 และจะอยู่ครู่หนึ่งก่อนที่คุณจะเห็นใน Windows version. แต่การใช้งาน 2FA บางอย่างอาจจำเป็นต้องใช้นาฬิกาแบบซิงโครไนซ์เสมอ)
การมีนาฬิกาซิงค์ทำให้ง่ายต่อการทำงานกับระบบที่แตกต่างกัน ตัวอย่างเช่นรายการบันทึกที่สัมพันธ์กันจากหลายเซิร์ฟเวอร์จะง่ายกว่ามากหากทุกระบบมีเวลาเดียวกัน ในกรณีเหล่านี้โดยปกติคุณสามารถทำงานได้ด้วยความอดทน 1 วินาทีซึ่ง NTP จะให้บริการ แต่คุณต้องการให้เวลาตรงกันมากที่สุดเท่าที่จะทำได้ PTP ซึ่งให้ความคลาดเคลื่อนที่เข้มงวดมากขึ้นอาจมีราคาแพงกว่าในการติดตั้ง
makeนอกจากนี้ยังสับสนโดยนาฬิกา skews ระหว่างไคลเอนต์ / เซิร์ฟเวอร์ NFS
ส่วนใหญ่เป็นเพื่อให้คุณสามารถเชื่อมโยงเหตุการณ์จากบันทึกบนอุปกรณ์ต่าง ๆ สมมติว่าคุณมีเหตุการณ์ด้านความปลอดภัยที่มีคนเข้าถึงฐานข้อมูลของคุณผ่านเว็บเซิร์ฟเวอร์ของคุณ - คุณต้องการเวลาประทับบนไฟร์วอลล์, load balancer ของคุณ, เว็บเซิร์ฟเวอร์ของคุณและเซิร์ฟเวอร์ฐานข้อมูลของคุณให้ตรงกับทั้งหมดเพื่อให้คุณสามารถค้นหาบันทึกในแต่ละอุปกรณ์ ที่เกี่ยวข้องกับเหตุการณ์ เป็นการดีที่คุณต้องการให้ทุกอย่างอยู่ในเสี้ยววินาที และจำเป็นต้องซิงค์กับเวลาภายนอกจริงเพื่อให้คุณสามารถเชื่อมโยงบันทึกของคุณกับบันทึกของบุคคลที่สามได้หากจำเป็น
ไม่เพียง แต่เป็นสิ่งสำคัญจากมุมมองของการจัดการ แต่การมีนาฬิกาซิงค์ของฉันสำคัญจากความสัมพันธ์ระดับแอปพลิเคชันด้วย ขึ้นอยู่กับว่าโซลูชันได้รับการออกแบบอย่างไรแอปพลิเคชันที่ทำงานจะได้รับการประทับเวลาสำหรับธุรกรรมใด ๆ ที่พวกเขาอาจทำงานด้วย ฉันเคยเห็นการตรวจสอบความถูกต้องของธุรกรรมล้มเหลวเนื่องจากแอปพลิเคชันที่ทำงานบนเซิร์ฟเวอร์ที่มีออฟเซ็ตมากเกินไป (ในอีกประมาณ 20 วินาทีในอนาคต) เมื่อเทียบกับที่อื่น ๆ ที่โต้ตอบกับมัน
นอกจากนี้หากการจำลองเสมือนบนเซิร์ฟเวอร์ VMWare ESXi และเวลาของ VM ไม่ซิงค์กับไฮเปอร์ไวเซอร์การกระทำเช่น vmotion อาจซิงค์นาฬิกา VM กับไฮเปอร์ไวเซอร์อีกครั้งและสิ่งนี้จะนำไปสู่ผลลัพธ์ที่ไม่สามารถคาดการณ์ได้ ถ้าความแตกต่างของเวลามีขนาดใหญ่พอ
ฉันไม่ทราบว่ามีความคลาดเคลื่อนจริงใด ๆ เพราะฉันคิดว่ามันขึ้นอยู่กับประเภทของระบบที่มีอยู่มากมาย แต่ฉันคิดว่าโดยทั่วไปแล้วการพูดมันสามารถทำได้เพื่อให้เซิร์ฟเวอร์ในศูนย์ข้อมูลมีเวลาน้อยกว่าหนึ่งวินาที
เมื่อคุณกล่าวถึงวินาทีกระโดดควรสังเกตว่าพวกเขาต้องการการจัดการที่ยากเป็นพิเศษ
พวกเขามักจะเพิ่มโดยการฉีดที่สองเป็น 23:59:60 นี่เป็นปัญหาถ้าคุณตรวจสอบการประทับเวลาเป็น 0-59 สำหรับฟิลด์นาทีและวินาที ทางเลือกในการทำซ้ำ 23:59:59 เพื่อทำให้มันยาว 2 วินาทีนั้นไม่ค่อยดีนักเนื่องจากมันจะยุ่งกับสิ่งต่าง ๆ ที่มีความอ่อนไหวต่อจังหวะเวลาจนถึงระดับต่อวินาที
Google มาพร้อมกับวิธีแก้ปัญหาที่ดีสักพักหนึ่งซึ่งดูเหมือนว่ายังไม่ได้รับการยอมรับ ทางออกของพวกเขาคือการใช้การกระโดด "smear" และแยกการเปลี่ยนแปลงในช่วงระยะเวลาหนึ่งกระบวนการทั้งหมดที่จัดการโดยเซิร์ฟเวอร์ NTP พวกเขาเผยแพร่บล็อกเกี่ยวกับมันในปี 2011 ทำให้อ่านน่าสนใจและดูเหมือนว่าเกี่ยวข้องกับคำถามนี้
เมื่อใดก็ตามที่เกี่ยวข้องกับการประทับเวลาอุปกรณ์ที่ถูกซิงโครไนซ์สามารถสร้างการเชื่อมโยงแบบลอจิคัลเช่น: A ส่งแบบสอบถามไปยัง B และการตอบกลับของ B มาพร้อมกับการประทับเวลาก่อนหน้าของแบบสอบถามอาจทำให้ A ไม่สนใจ
ฉันเห็นด้วยกับทุกประเด็นข้างต้น ฉันต้องการที่จะโยนความคิดเพิ่มเติม
ฐานข้อมูลบางอย่างเช่นCassendra พึ่งพาการลงเวลาอย่างมาก นั่นคือวิธีจัดการกับการเกิดพร้อมกัน
การประทับเวลาที่แตกต่างกันจะทำให้ฐานข้อมูลยุ่งเหยิง