Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Операциялық жүйелер ресурстарға қол жеткізуді ұйымдастыру және реттілікке келтіру үшін құлып менеджерлерін пайдаланады. Бөлінген құлып менеджері (DLM) кластердегі әрбір машинада кластерлік құлып дерекқорының бірдей көшірмесімен жұмыс істейді. Осылайша, DLM бірнеше машинада кластерде таратылған бағдарламалық қамтамасыздарға ортақ ресурстарға қол жеткізуді синхрондау құралын ұсынады. DLM бірнеше сәтті кластерлік файлдық жүйелердің негізі ретінде қолданылды, онда кластердегі машиналар бірыңғай файлдық жүйе арқылы бір-бірінің сақтағыштарын пайдалана алады, бұл өнімділік және қол жетімділік үшін маңызды артықшылықтар береді. Басты өнімділік артықшылығы қатысушы компьютерлер арасындағы дискілік кэш сәйкестігі мәселесін шешуден туындайды. DLM файлдарды құлыптау үшін ғана емес, сонымен қатар барлық дискіге қол жеткізуді үйлестіру үшін де қолданылады. Кенде тараған алғашқы кластерлік жүйе болған VMScluster, осылай OpenVMS DLM-ге сүйенді.
Operating systems use lock managers to organise and serialise the access to resources. A distributed lock manager (DLM) runs in every machine in a cluster, with an identical copy of a cluster wide lock database. In this way a DLM provides software applications which are distributed across a cluster on multiple machines with a means to synchronize their accesses to shared resources. DLMs have been used as the foundation for several successful clustered file systems, in which the machines in a cluster can use each other's storage via a unified file system, with significant advantages for performance and availability. The main performance benefit comes from solving the problem of disk cache coherency between participating computers. The DLM is used not only for file locking but also for coordination of all disk access. VMScluster, the first clustering system to come into widespread use, relied on the OpenVMS DLM in just this way.
Блокты алу
Процесс ресурстың бұғатталуын алу үшін бұғаттау сұранысын кезекке қояды. Бұл I/O операцияларын жүзеге асыру үшін қолданылатын QIO техникасына ұқсас. Кезектегі бұғаттау сұранысы синхронды түрде орындалуы мүмкін, яғни процесс бұғаттау берілгенше күтеді, немесе асинхронды түрде, яғни бұғаттау алынған кезде AST (асинхронды жағдай туралы хабарлама) пайда болады. Сонымен қатар, басқа процесс ресурстың бұғатталуын алғанда, оның басқа процестерге қолжетімділігін шектеуі мүмкін, және осы жағдайда бұғаттау AST іске қосылады. Алғашқы процесс басқа процеске қолжетімділікті қамтамасыз ету үшін (мысалы, бұғаттау деңгейін төмендету немесе оны босату арқылы) қосымша шаралар қолдануы мүмкін.
A process can obtain a lock on a resource by enqueueing a lock request. This is similar to the QIO technique that is used to perform I/O. The enqueue lock request can either complete synchronously, in which case the process waits until the lock is granted, or asynchronously, in which case an AST occurs when the lock has been obtained. It is also possible to establish a blocking AST, which is triggered when a process has obtained a lock that is preventing access to the resource by another process. The original process can then optionally take action to allow the other access (e. g. by demoting or releasing the lock).
Қалқаның мәні
Әрбір ресурсқа кілт мәні блогы байланыстырылады. Бұл блокты ресурсты бұғаттаған кез келген процесс оқи алады (нольдік бұғаттамадан басқа), ал қорғалған жаңарту немесе эксклюзивті бұғаттама алған процесс жаңарта алады. Ол қолданба жасаушы таңдаған ресурс туралы кез келген ақпаратты сақтау үшін пайдаланылуы мүмкін. Көбінесе ресурстың нұсқа нөмірін сақтау үшін қолданылады. Қатысты нысан (мысалы, деректер базасы жазбасы) жаңартылған сайын, бұғаттама иесі кілт мәні блогының мәнін арттырады. Басқа процесс ресурсты оқығысы келгенде, тиісті бұғаттаманы алып, ағымдағы кілт мәнін процесс соңғы рет ресурсты бұғаттаған кездегі мәнмен салыстырады. Егер мәндер бірдей болса, процесс байланысты нысан соңғы оқудан бері жаңартылмағанын біледі, демек оны қайта оқудың қажеті жоқ. Осылайша, бұл техника деректер базасында немесе ұқсас қолданбада кэштің түрлі түрлерін жүзеге асыру үшін қолданылуы мүмкін.
A lock value block is associated with each resource. This can be read by any process that has obtained a lock on the resource (other than a null lock) and can be updated by a process that has obtained a protected update or exclusive lock on it. It can be used to hold any information about the resource that the application designer chooses. A typical use is to hold a version number of the resource. Each time the associated entity (e. g. a database record) is updated, the holder of the lock increments the lock value block. When another process wishes to read the resource, it obtains the appropriate lock and compares the current lock value with the value it had last time the process locked the resource. If the value is the same, the process knows that the associated entity has not been updated since last time it read it, and therefore it is unnecessary to read it again. Hence, this technique can be used to implement various types of cache in a database or similar application.
Мөлдір тұйықтықты анықтау
Бір немесе бірнеше процесс ресурстарға құлып қойған кезде, олардың әрқайсысы екінші процеске құлып қоюға кедергі келтіретін және ешқайсысы да алға жылжуға мүмкін болмайтын жағдай тууы мүмкін. Бұл тұйыққа түсу (deadlock) деп аталады (Э. В. Дейкстра бастапқыда оны «өлім құшағы» деп атаған). Мысалы, 1-процесс А ресурсына эксклюзивті құлып қойса, ал 2-процесс В ресурсына эксклюзивті құлып қойса, тұйыққа түсу пайда болуы мүмкін. Егер 1-процесс B ресурсын құлыптауға тырысса, ол 2-процесс оны босатуын күтуі керек. Бірақ егер 2-процесс А ресурсын құлыптауға тырысса, екі процесс те бірін-бірі шексіз күтеді. OpenVMS DLM тұрақты түрде тұйыққа түсу жағдайларын тексеріп отырады. Жоғарыдағы мысалда, процестердің бірінің екінші құлыптау сұранысы тұйыққа түсу күйімен қайтарылады. Осы процеске тұйыққа түсуді шешу үшін шара қолдану қажет болады – бұл жағдайда алғашқы құлыпты босату арқылы.
When one or more processes have obtained locks on resources, it is possible to produce a situation where each is preventing another from obtaining a lock, and none of them can proceed. This is known as a deadlock (E. W. Dijkstra originally called it a deadly embrace). A simple example is when Process 1 has obtained an exclusive lock on Resource A, and Process 2 has obtained an exclusive lock on Resource B. If Process 1 then tries to lock Resource B, it will have to wait for Process 2 to release it. But if Process 2 then tries to lock Resource A, both processes will wait forever for each other. The OpenVMS DLM periodically checks for deadlock situations. In the example above, the second lock enqueue request of one of the processes would return with a deadlock status. It would then be up to this process to take action to resolve the deadlock—in this case by releasing the first lock it obtained.
Linux кластерлеуі
Red Hat және Oracle екеуі де Linux үшін кластерлік бағдарламалық жасақтаманы әзірледі. OCFS2, Oracle Cluster File System 2006 жылдың қаңтарында 2.6.16 нұсқасымен ресми Linux ядросына қосылды. 2.6.19 нұсқасында OCFS2-нің альфа сапалы код ескертуі алынып тасталды. Red Hat-тың кластерлік бағдарламалық жасақтамасы, оның ішінде DLM және GFS2 2006 жылдың қарашасында 2.6.19 нұсқасымен ресми түрде Linux ядросына қосылды. Екі жүйе де VMS DLM үлгісіндегі DLM-ді пайдаланады. Oracle-тің DLM-і қарапайым API-ға ие. (Оның негізгі функциясы, dlmlock, сегіз параметрден тұрады, ал VMS SYS$ENQ қызметі мен Red Hat-тың dlm lock-і екеуінде де 11 параметр бар.)
Both Red Hat and Oracle have developed clustering software for Linux. OCFS2, the Oracle Cluster File System was added to the official Linux kernel with version 2.6.16, in January 2006. The alpha quality code warning on OCFS2 was removed in 2.6.19. Red Hat's cluster software, including their DLM and GFS2 was officially added to the Linux kernel with version 2.6.19, in November 2006. Both systems use a DLM modeled on the venerable VMS DLM. Oracle's DLM has a simpler API. (the core function, dlmlock , has eight parameters, whereas the VMS SYS$ENQ service and Red Hat's dlm lock both have 11.)