ตัวจัดการล็อกแบบกระจาย ( DLM ) ทำงานในทุกเครื่องในคลัสเตอร์ โดยมีสำเนาฐานข้อมูลล็อกที่เหมือนกันทั่วทั้งคลัสเตอร์ระบบปฏิบัติการใช้ตัวจัดการล็อกเพื่อจัดระเบียบและจัดลำดับการเข้าถึงทรัพยากร ด้วยวิธีนี้ DLM จึงช่วยให้แอปพลิเคชันซอฟต์แวร์ที่กระจายอยู่ทั่วคลัสเตอร์บนเครื่องหลายเครื่องมีวิธีการในการซิงโครไนซ์การเข้าถึงทรัพยากรที่ใช้ร่วมกัน

DLM (Distributed Disk Management) ถูกนำมาใช้เป็นพื้นฐานสำหรับระบบไฟล์แบบคลัสเตอร์ ที่ประสบความสำเร็จหลายระบบ ซึ่งเครื่องในคลัสเตอร์สามารถใช้พื้นที่จัดเก็บข้อมูลของกันและกันผ่านระบบไฟล์ แบบรวมศูนย์ โดยมีข้อดีอย่างมากในด้านประสิทธิภาพและความพร้อมใช้งาน ประโยชน์หลักด้านประสิทธิภาพมาจากการแก้ปัญหาความสอดคล้องของแคชดิสก์ระหว่างคอมพิวเตอร์ที่เข้าร่วม DLM ไม่ได้ใช้เพียงแค่สำหรับการล็อกไฟล์ เท่านั้น แต่ยังใช้สำหรับการประสานงานการ เข้าถึงดิสก์ทั้งหมดด้วยVMSclusterซึ่งเป็นระบบคลัสเตอร์ระบบแรกที่ใช้งานกันอย่างแพร่หลาย ก็ใช้ DLM ของ OpenVMSในลักษณะนี้เช่นกัน

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

• ฐานข้อมูล
• โต๊ะ
• บันทึก
• สนาม

จากนั้น กระบวนการสามารถล็อกฐานข้อมูลทั้งหมดได้ และจากนั้นจึงล็อกส่วนต่างๆ ของฐานข้อมูลได้ จะต้องล็อกทรัพยากรหลักก่อนจึงจะสามารถล็อกทรัพยากรย่อย ได้

กระบวนการที่ทำงานอยู่ภายใน VMSCluster อาจได้รับสิทธิ์ในการล็อกทรัพยากร มีโหมดการล็อกหกโหมดที่สามารถให้ได้ และโหมดเหล่านี้จะกำหนดระดับการผูกขาดที่ได้รับ สามารถเปลี่ยนระดับการล็อกเป็นระดับที่สูงขึ้นหรือต่ำลงได้ เมื่อกระบวนการทั้งหมดปลดล็อกทรัพยากรแล้ว ข้อมูลของระบบเกี่ยวกับทรัพยากรนั้นจะถูกทำลาย

• ค่าว่าง (Null) (NL) แสดงถึงความสนใจในทรัพยากร แต่ไม่ได้ป้องกันกระบวนการอื่นจากการล็อกทรัพยากรนั้น ข้อดีคือ ทรัพยากรและบล็อกค่าการล็อกจะยังคงอยู่ แม้ว่าจะไม่มีกระบวนการใดล็อกอยู่ก็ตาม
• การอ่านพร้อมกัน (Concurrent Read หรือ CR) บ่งชี้ถึงความต้องการที่จะอ่าน (แต่ไม่อัปเดต) ทรัพยากร โดยอนุญาตให้กระบวนการอื่นอ่านหรืออัปเดตทรัพยากรได้ แต่ป้องกันไม่ให้กระบวนการอื่นเข้าถึงทรัพยากรนั้นแต่เพียงผู้เดียว โดยทั่วไปจะใช้กับทรัพยากรระดับสูง เพื่อให้สามารถล็อกทรัพยากรระดับรองลงมาได้อย่างเข้มงวดมากขึ้น
• การเขียนพร้อมกัน (Concurrent Write หรือ CW) แสดงถึงความต้องการที่จะอ่านและอัปเดตทรัพยากร นอกจากนี้ยังอนุญาตให้กระบวนการอื่นอ่านหรืออัปเดตทรัพยากรได้ แต่ป้องกันไม่ให้กระบวนการอื่นเข้าถึงทรัพยากรนั้นแต่เพียงผู้เดียว โดยทั่วไปแล้วจะใช้กับทรัพยากรระดับสูง เพื่อให้สามารถล็อกทรัพยากรระดับรองลงมาได้อย่างเข้มงวดมากขึ้น
• สิทธิ์การอ่านที่ได้รับการป้องกัน (Protected Read หรือ PR) นี่คือการล็อกการแชร์ แบบดั้งเดิม ซึ่งบ่งบอกถึงความต้องการที่จะอ่านทรัพยากร แต่ป้องกันไม่ให้ผู้อื่นแก้ไขเปลี่ยนแปลงได้ อย่างไรก็ตาม ผู้อื่นก็ยังสามารถอ่านทรัพยากรนั้นได้
• การเขียนที่ได้รับการป้องกัน (Protected Write - PW) นี่คือการล็อกการอัปเดต แบบดั้งเดิม ซึ่งบ่งชี้ถึงความต้องการที่จะอ่านและอัปเดตทรัพยากร และป้องกันไม่ให้ผู้อื่นอัปเดตทรัพยากรนั้น อย่างไรก็ตาม ผู้ที่มีสิทธิ์เข้าถึงแบบอ่านพร้อมกัน (Concurrent Read) สามารถอ่านทรัพยากรได้
• สิทธิ์การเข้าถึงแบบพิเศษ (EX) นี่คือการล็อกแบบพิเศษ ดั้งเดิม ที่อนุญาตให้เข้าถึงแบบอ่านและอัปเดตทรัพยากร และป้องกันไม่ให้ผู้อื่นเข้าถึงได้

ตารางความจริงต่อไปนี้แสดงความเข้ากันได้ของโหมดการล็อกแต่ละแบบกับโหมดอื่นๆ:

กระบวนการสามารถขอสิทธิ์ในการล็อกทรัพยากรได้โดยการส่งคำขอล็อกเข้าคิว ซึ่งคล้ายกับ เทคนิค QIOที่ใช้ในการดำเนินการ I/O การส่งคำขอล็อกเข้าคิวสามารถเสร็จสมบูรณ์ได้ทั้งแบบซิงโครนัส ซึ่งในกรณีนี้กระบวนการจะรอจนกว่าจะได้รับสิทธิ์ล็อก หรือแบบอะซิงโครนัส ซึ่งในกรณีนี้ จะเกิด ASTขึ้นเมื่อได้รับสิทธิ์ล็อกแล้ว

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

แต่ละทรัพยากรจะมีบล็อกค่าล็อกที่เชื่อมโยงอยู่ กระบวนการใดๆ ที่ได้รับล็อกบนทรัพยากรนั้น (ยกเว้นล็อกว่าง) สามารถอ่านบล็อกค่าล็อกนี้ได้ และกระบวนการที่ได้รับล็อกแบบป้องกันการอัปเดตหรือล็อกแบบพิเศษสามารถอัปเดตบล็อกค่าล็อกนี้ได้

สามารถใช้เก็บข้อมูลใดๆ เกี่ยวกับทรัพยากรที่นักออกแบบแอปพลิเคชันเลือกได้ ตัวอย่างการใช้งานทั่วไปคือการเก็บหมายเลขเวอร์ชันของทรัพยากร ทุกครั้งที่เอนทิตีที่เกี่ยวข้อง (เช่น เรคอร์ดในฐานข้อมูล) ได้รับการอัปเดต ผู้ถือล็อกจะเพิ่มค่าบล็อกล็อกขึ้น เมื่อกระบวนการอื่นต้องการอ่านทรัพยากร กระบวนการนั้นจะขอรับล็อกที่เหมาะสมและเปรียบเทียบค่าล็อกปัจจุบันกับค่าที่ได้ในครั้งล่าสุดที่กระบวนการนั้นล็อกทรัพยากร หากค่าเหมือนกัน กระบวนการนั้นจะรู้ว่าเอนทิตีที่เกี่ยวข้องไม่ได้ถูกอัปเดตตั้งแต่ครั้งล่าสุดที่อ่าน และดังนั้นจึงไม่จำเป็นต้องอ่านอีกครั้ง ด้วยเหตุนี้ เทคนิคนี้จึงสามารถนำไปใช้ในการสร้างแคช ประเภทต่างๆ ในฐานข้อมูลหรือแอปพลิเคชันที่คล้ายกันได้

เมื่อกระบวนการหนึ่งหรือมากกว่านั้นได้รับล็อกบนทรัพยากร อาจเกิดสถานการณ์ที่แต่ละกระบวนการขัดขวางไม่ให้กระบวนการอื่นได้รับล็อก และไม่มีกระบวนการใดสามารถดำเนินการต่อไปได้ สถานการณ์นี้เรียกว่าภาวะติดตาย ( เดิมทีEW Dijkstra เรียกมันว่า การโอบกอดอันร้ายแรง ) ^{[ 1 ]}

ตัวอย่างง่ายๆ คือ เมื่อกระบวนการที่ 1 ได้รับการล็อกแบบพิเศษบนทรัพยากร A และกระบวนการที่ 2 ได้รับการล็อกแบบพิเศษบนทรัพยากร B หากกระบวนการที่ 1 พยายามล็อกทรัพยากร B จะต้องรอให้กระบวนการที่ 2 ปล่อยการล็อกก่อน แต่ถ้ากระบวนการที่ 2 พยายามล็อกทรัพยากร A ทั้งสองกระบวนการจะต้องรอซึ่งกันและกันไปตลอดกาล

ระบบ OpenVMS DLM จะตรวจสอบสถานการณ์การติดตาย (deadlock) เป็นระยะ ในตัวอย่างข้างต้น คำขอเข้าคิวล็อกครั้งที่สองของกระบวนการหนึ่งจะส่งคืนสถานะติดตาย จากนั้นกระบวนการนั้นจะต้องดำเนินการเพื่อแก้ไขการติดตาย ซึ่งในกรณีนี้คือการปล่อยล็อกแรกที่ได้รับมา

ทั้งRed HatและOracleต่างพัฒนาซอฟต์แวร์คลัสเตอร์สำหรับ Linux

OCFS2ซึ่งเป็น Oracle Cluster File System ถูกเพิ่ม^{[ 2 ]}ลงในเคอร์เนล Linux อย่างเป็นทางการ ในเวอร์ชัน 2.6.16 ในเดือนมกราคม พ.ศ. 2549 คำเตือนเกี่ยวกับโค้ดคุณภาพอัลฟ่าของ OCFS2 ถูกลบออกในเวอร์ชัน 2.6.19

ซอฟต์แวร์คลัสเตอร์ของ Red Hat รวมถึง DLM และGFS2ได้รับการเพิ่มอย่างเป็นทางการในเคอร์เนล Linux ^{[ 3 ]}ในเวอร์ชัน 2.6.19 ในเดือนพฤศจิกายน พ.ศ. 2549

ทั้งสองระบบใช้ DLM ที่จำลองมาจาก VMS DLM ที่มีชื่อเสียง^{[ 4 ]} DLM ของ Oracle มี API ที่เรียบง่ายกว่า (ฟังก์ชันหลักdlmlock()มีพารามิเตอร์แปดตัว ในขณะที่บริการ VMS SYS$ENQและ Red Hat dlm_lockมีพารามิเตอร์ 11 ตัว)

รูปแบบการใช้งาน DLM อื่นๆ ได้แก่:

• Googleได้พัฒนาChubbyซึ่งเป็นบริการล็อกสำหรับระบบกระจายแบบหลวมๆ^{[ 5 ]}ออกแบบมาเพื่อการล็อกแบบหยาบๆ และยังให้บริการระบบไฟล์แบบกระจายที่มีข้อจำกัดแต่เชื่อถือได้อีกด้วย ส่วนสำคัญของโครงสร้างพื้นฐานของ Google รวมถึงGoogle File System , BigtableและMapReduce ใช้ Chubby เพื่อซิงโครไนซ์การเข้าถึงทรัพยากรที่ใช้ร่วมกัน แม้ว่า Chubby จะ ^ได้รับการออกแบบให้เป็นบริการล็อก แต่ปัจจุบันมีการใช้งานอย่างแพร่หลายภายใน Google ในฐานะเซิร์ฟเวอร์ชื่อแทนที่DNS [ ^{5 ]}
• Apache ZooKeeperซึ่งสร้างขึ้นที่Yahooเป็นซอฟต์แวร์โอเพนซอร์สและสามารถใช้เพื่อทำการล็อกแบบกระจาย^{[ 6 ]}ได้เช่นกัน
• Etcdเป็นซอฟต์แวร์โอเพนซอร์สที่พัฒนาโดยCoreOSภายใต้Apache License ^{[ 7 ]} นอกจากนี้ยังสามารถใช้เพื่อทำการล็อกแบบกระจายได้อีกด้วย^{[ 8 ]}
• Redisเป็นโอเพนซอร์สที่ได้รับอนุญาตภายใต้ Redis Source Available License ซึ่งเป็นแคชและที่เก็บข้อมูลแบบคีย์-ค่าขั้นสูง^{[ 9 ]} Redis สามารถนำมาใช้เพื่อนำอัลกอริทึม Redlock มาใช้สำหรับการจัดการล็อกแบบกระจาย^{[ 10 ]}
• ConsulของHashiCorp ^{[ 11 ]}ซึ่งสร้างโดยHashiCorpเป็นซอฟต์แวร์โอเพนซอร์สและสามารถใช้เพื่อทำการล็อกแบบกระจายได้เช่นกัน
• ตัวจัดการล็อกแบบกระจาย Taooka ^{[ 12 ]}ใช้เมธอด "try lock" เพื่อหลีกเลี่ยงการติดตายนอกจากนี้ยังสามารถระบุ TTL สำหรับแต่ละล็อกด้วยความแม่นยำระดับนาโนวินาทีได้อีกด้วย
• DLM ยังเป็นส่วนประกอบสำคัญของ โครงการ Single System Image (SSI) ที่มีความทะเยอทะยานมากขึ้น เช่นOpenSSIอีก ด้วย