DLM Support for MTS and XA
lock ownership that may be available with your DLM:
group-based ownership
With group-based locking, ownership becomes dynamic: a single lock can be shared by two or more processes belonging to the same group. Processes in the same group can share the lock without going to the DLM grant and convert queues.
Group-based locking is an important DLM feature if you wish to use Oracle multi-threaded server (MTS) or XA library functionality.
Group-based locking is strongly recommended for Oracle MTS configurations. Without it, sessions cannot migrate between shared server processes. In addition, load balancing may be affected, especially with long running transactions.
XA libraries
With Oracle XA libraries, multiple sessions or processes can work on the transaction; they therefore need to share the same locks, even in exclusive mode. With group-based lock ownership, processes can share access to an exclusive resource.
Кластеризация Linux
И Red Hat, и Oracle разработали программное обеспечение для кластеризации для Linux .
OCFS2 , кластерная файловая система Oracle, была добавлена в официальное ядро Linux с версией 2.6.16 в январе 2006 года. Предупреждение о альфа-качестве кода для OCFS2 было удалено в 2.6.19.
Кластерное программное обеспечение Red Hat, включая их DLM и GFS2, было официально добавлено в ядро Linux с версией 2.6.19 в ноябре 2006 года.
Обе системы используют DLM, смоделированный на почтенном VMS DLM. Oracle DLM имеет более простой API. (основная функция имеет восемь параметров, тогда как служба VMS и Red Hat имеют 11.)
Будущее cLVM — lvmlockd
Это другой подход к реализации cLVM. Здесь не нужен кластер менеджмент вообще. Блокировки объявляются не по сети — через общую шину кластера а пишутся прямо на диск(который общий)! Это снимает ограничение на количество нод в кластере. Теоретически в таком кластере может быть до 2000 нод.
Но есть и минусы. Этот механизм не готов к промышленной эксплуатации. Часть функциональности еще на экспериментальной стадии. Доступен только в rhel 7.1 и выше.
Настройка
На всех нодах:
yum install lvm2-lockd sanlock -y
vim /etc/lvm/lvm.conf_x000D_ _x000D_ locking_type = 1_x000D_ use_lvmlockd = 1
Задать уникальный(1-2000) host_id на каждой ноде:
vim /etc/lvm/lvmlocal.conf
systemctl start lvm2-lvmlockd wdmd sanlock
Создание VG
vgcreate --shared <vgname> <devices>
на других нодах, что бы иметь возможность работать с shared VG:
vgchange --lock-start <vgname>
Создание LV
lvcreate --name <name> --size 10Gb <vgname>
после создания, LV сразу же имеет статус ACTIVE и для нее создается DM девайс и симлинк в /dev на этой ноде.
Если нужно, использовать LV на другой ноде, прежде его нужно деактивировать:
lvchange -aln /dev/test/t1
Это приводит к удалению DM деваса и перевод LV в статус ‘inactive’
На ноде на которой нужен этот LV, его нужно активировать:
Активировать эксклюзивно. Это не даст возможности активировать кому то еще. Ресайз LV можно сделать только активировав эксклюзивно.
lvchange -aey /dev/test/t1
Активировать не эксклюзивно. Другие ноды тоже смогут его активировать. Но, сделать ресайз не получится. Пока, что это не поддерживается.
lvchange -asy /dev/test/t1
Активация приводит к созданию DM девайса и симлинка для него.
Ресайз LV
Делается как обычно, когда LV активирован эксклюзивно.
Другие ограничения, которые пока еще не решены
limitations of lockd VGs Things that do not yet work in lockd VGs: · creating a new thin pool and a new thin LV in a single command · using lvcreate to create cache pools or cache LVs (use lvconvert) · using external origins for thin LVs · splitting mirrors and snapshots from LVs · vgsplit · vgmerge · resizing an LV that is active in the shared mode on multiple hosts
подробный man http://man7.org/linux/man-pages/man8/lvmlockd.8.html
The synchrony assumptions of Redlock
These examples show that Redlock works correctly only if you assume a synchronous system model –
that is, a system with the following properties:
- bounded network delay (you can guarantee that packets always arrive within some guaranteed maximum
delay), - bounded process pauses (in other words, hard real-time constraints, which you typically only
find in car airbag systems and suchlike), and - bounded clock error (cross your fingers that you don’t get your time from a bad NTP
server).
Note that a synchronous model does not mean exactly synchronised clocks: it means you are assuming
a known, fixed upper bound on network delay, pauses and clock drift . Redlock
assumes that delays, pauses and drift are all small relative to the time-to-live of a lock; if the
timing issues become as large as the time-to-live, the algorithm fails.
In a reasonably well-behaved datacenter environment, the timing assumptions will be satisfied most
of the time – this is known as a partially synchronous system . But is that good
enough? As soon as those timing assumptions are broken, Redlock may violate its safety properties,
e.g. granting a lease to one client before another has expired. If you’re depending on your lock for
correctness, “most of the time” is not enough – you need it to always be correct.
There is plenty of evidence that it is not safe to assume a synchronous system model for most
practical system environments . Keep reminding yourself of the GitHub incident with the
90-second packet delay. It is unlikely that Redlock would survive a Jepsen test.
On the other hand, a consensus algorithm designed for a partially synchronous system model (or
asynchronous model with failure detector) actually has a chance of working. Raft, Viewstamped
Replication, Zab and Paxos all fall in this category. Such an algorithm must let go of all timing
assumptions. That’s hard: it’s so tempting to assume networks, processes and clocks are more
reliable than they really are. But in the messy reality of distributed systems, you have to be very
careful with your assumptions.
Release notes
- 2.2.0
- 2.1.0
- 2.0.2
- Fixed bug where would hang when accessed on a SqlServer or Postgres lock handle that used keepalive (#85, DistributedLock.Core 1.0.1)
- Fixed bug where broken database connections could result in future lock attempts failing when using SqlServer or Postgres locks with multiplexing (#83, DistributedLock.Core 1.0.1)
- Updated Npgsql dependency to 5.x to take advantage of various bugfixes (#61, DistributedLock.Postgres 1.0.1)
- 2.0.1
- 2.0.0 (see also )
- Revamped package structure so that DistributedLock is now an umbrella package and each implementation technology has its own package (BREAKING CHANGE)
- Added Postgresql-based locking (#56, DistributedLock.Postgres 1.0.0)
- Added Redis-based locking (#24, DistributedLock.Redis 1.0.0)
- Added Azure blob-based locking (#42, DistributedLock.Azure 1.0.0)
- Added file-based locking (#28, DistributedLock.FileSystem 1.0.0)
- Added provider classes for improved IOC integration (#13)
- Added strong naming to assemblies. Thanks @pedropaulovc for contributing! (#47, BREAKING CHANGE)
- Made lock handles implement in addition to #20, BREAKING CHANGE)
- Exposed implementation-agnostic interfaces (e. g. ) for all synchronization primitives (#10)
- Added API for tracking if a lock’s underlying connection dies (#6, BREAKING CHANGE)
- Added SourceLink support (#57)
- Removed API in favor of safe naming by default (BREAKING CHANGE)
- Renamed «SystemDistributedLock» to «EventWaitHandleDistributedLock» (DistributedLock.WaitHandles 1.0.0)
- Stopped supporting net45 (BREAKING CHANGE)
- Removed and constructors form , leaving the constructors that take / (#35, BREAKING CHANGE)
- Changed methods returning to instead return , making it so that await` no longer compiles (#34, BREAKING CHANGE)
- Changed to return (#33, BREAKING CHANGE)
- Switched to Microsoft.Data.SqlClient by default for all target frameworks (BREAKING CHANGE)
- Changed all locking implementations to be non-reentrant (BREAKING CHANGE)
- 1.5.0
- Added cross-platform support via Microsoft.Data.SqlClient (#25). This feature is available for .NET Standard >= 2.0. Thanks to @alesebi91 for helping with the implementation and testing!
- Added C#8 nullable annotations (#31)
- Fixed minor bug in connection multiplexing which could lead to more lock contention (#32)
- 1.4.0
- Added a SQL-based distributed semaphore (#7)
- Fix bug where SqlDistributedLockConnectionStrategy.Azure would leak connections, relying on GC to reclaim them (#14). Thanks zavalita1 for investigating this issue!
- Throw a specific exception type () rather than the generic when a deadlock is detected (#11)
- 1.3.1 Minor fix to avoid «leaking» isolation level changes in transaction-based locks (#8). Also switched to the VS2017 project file format
- 1.3.0 Added an Azure connection strategy to keep lock connections from becoming idle and being reclaimed by Azure’s connection governor (#5)
- 1.2.0
- Added a SQL-based distributed reader-writer lock
- .NET Core support via .NET Standard
- Changed the default locking scope for SQL distributed lock to be a connection rather than a transaction, avoiding cases where long-running transactions can block backups
- Allowed for customization of the SQL distributed lock connection strategy when connecting via a connection string
- Added a new connection strategy which allows for multiplexing multiple held locks onto one connection
- Added IDbConnection/IDbTransaction constructors (#3)
- 1.1.0 Added support for SQL distributed locks scoped to existing connections/transactions
- 1.0.1 Minor fix when using infinite timeouts
- 1.0.0 Initial release
IDLM Lock Modes: Resource Access Rights
Instances use locks to obtain various rights to a resource. A lock may be initially created on a resource with no access rights granted. Later, a process converts the lock to obtain new access rights.
illustrates the levels of access rights or «lock modes» available through the IDLM.
Figure 8-4 IDLM Lock Modes: Levels of Access
Table 8-1 Lock Mode Names
|
Oracle Mode |
Summary |
Description |
|
NULL |
Null mode. No lock is on the resource. |
Holding a lock at this level conveys no access rights. Typically, a lock is held at this level to indicate that a process is interested in a resource. Or it is used as a place holder. Once created, null locks ensure the requestor always has a lock on the resource; there is no need for the IDLM to constantly create and destroy locks when ongoing access is needed. |
|
SS |
Sub-shared mode (concurrent read). Read; there may be writers and other readers. |
When a lock is held at this level, the associated resource can be read in an unprotected fashion: other processes can read and write the associated resource. |
|
SX |
Shared exclusive mode (concurrent write). Write; there may be other readers and writers. |
When a lock is held at this level, the associated resource can be read or written in an unprotected fashion: other processes can both read and write the resource. |
|
S |
Shared mode (protected read). Read; no writers are allowed. |
When a lock is held at this level, a process cannot write the associated resource. Multiple processes can read the resource. This is the traditional shared lock. In shared mode, any number of users can have simultaneous read access to the resource. Shared access is appropriate for read operations. |
|
SSX |
Sub-shared exclusive mode (protected write). One writer only; there may be readers |
Only one process can hold a lock at this level. This allows a process to modify a resource without allowing other processes to simultaneously modify the resource at the same time. Other processes can perform unprotected reads. The traditional update lock. |
|
X |
Exclusive mode. Write; no other access is allowed |
When a lock is held at this level, it grants the holding process exclusive access to the resource. Other processes cannot read or write the resource. This is the traditional exclusive lock. |
Другие реализации
Другие реализации DLM включают следующее:
- разработал Chubby , сервис блокировки для слабосвязанных распределенных систем. Он разработан для крупномасштабной блокировки, а также предоставляет ограниченную, но надежную распределенную файловую систему. Ключевые части инфраструктуры Google, включая файловую систему Google , Bigtable и MapReduce , используют Chubby для синхронизации доступа к общим ресурсам. Хотя Chubby был разработан как служба блокировки, в настоящее время он активно используется внутри Google в качестве сервера имен , вытесняя DNS .
- Apache ZooKeeper , созданный в Yahoo , является программным обеспечением с открытым исходным кодом и может также использоваться для выполнения распределенных блокировок.
- Etcd — это программное обеспечение с открытым исходным кодом, разработанное CoreOS по лицензии Apache. Его также можно использовать для выполнения распределенных блокировок.
- Redis — это расширенный кеш-ключ и хранилище с открытым исходным кодом, лицензированный BSD. Redis может использоваться для реализации алгоритма Redlock для управления распределенными блокировками.
- HashiCorp в консулом , который был создан HashiCorp , является открытым исходным кодом и может быть использована для выполнения распределенных блокировок , а также.
- Диспетчер распределенных блокировок Taooka использует методы «пробной блокировки», чтобы избежать взаимоблокировок . Он также может указывать TTL для каждой блокировки с точностью до наносекунды.
- DLM также является ключевым компонентом более амбициозных проектов единого образа системы (SSI), таких как OpenSSI .
Механизм репликации
HDFS предназначен для надежного хранения очень больших файлов на машинах в большом кластере. Он хранит каждый файл в виде последовательности блоков; все блоки в файле, кроме последнего блока, имеют одинаковый размер. Блоки файлов реплицируются для отказоустойчивости. Размер блока и коэффициент репликации настраиваются для каждого файла. Приложение может указывать количество реплик файла. Коэффициент репликации может быть указан во время создания файла и может быть изменен позже. Файлы в HDFS записываются один раз и имеют строго одного автора в любое время.
NameNode принимает все решения относительно репликации блоков. Он периодически получает Heartbeat и Blockreport от каждого из DataNodes в кластере. Получение Heartbeat подразумевает, что DataNode функционирует должным образом. Blockreport содержит список всех блоков в DataNode.
При обнаружении NameNode-сервером отказа одного из DataNode-серверов (отсутствие heartbeat-сообщений от оного), запускается механизм репликации данных:
- выбор новых DataNode-серверов для новых реплик
- балансировка размещения данных по DataNode-серверам
Аналогичные действия производятся в случае повреждении реплик или в случае увеличения количества реплик присущих каждому блоку.
Размещение реплик имеет решающее значение для надежности и производительности HDFS. Оптимизация размещения реплик отличает HDFS от большинства других распределенных файловых систем. Это функция, которая требует большого количества настроек и опыта. Цель политики размещения реплик в стойке — повысить надежность, доступность и пропускную способность сети.
Большие экземпляры HDFS запускаются на кластере компьютеров, который обычно распространен на многие стойки. Связь между двумя узлами в разных стойках должна проходить через коммутаторы. В большинстве случаев пропускная способность сети между машинами в одной стойке больше, чем пропускная способность сети между машинами в разных стойках.
NameNode определяет идентификатор стойки, к которому принадлежит каждый DataNode, посредством процесса, описанного в Hadoop Rack Awareness. Простая, но неоптимальная политика заключается в размещении реплик на уникальных стойках. Это предотвращает потерю данных при сбое всей стойки и позволяет использовать полосу пропускания с нескольких стоек при чтении данных. Эта политика равномерно распределяет реплики в кластере, что упрощает балансировку нагрузки при сбое компонента. Тем не менее, эта политика увеличивает стоимость записи, поскольку запись требует передачи блоков на несколько стоек.
Для общего случая, когда коэффициент репликации равен трем, политика размещения HDFS заключается в том, чтобы поместить одну реплику на один узел в локальную стойку, другую на узел в другой (удаленной) стойке, а последнюю в другой узел в той же дистанционной стойке. Эта политика уменьшает трафик записи между стойками, что в целом повышает производительность записи. Вероятность сбоя в стойке намного меньше, чем отказ узла; эта политика не влияет на надежность и надежность данных. Тем не менее, он уменьшает совокупную пропускную способность сети, используемую при чтении данных, поскольку блок размещен только в двух уникальных стойках, а не в трех. С помощью этой политики реплики файла не равномерно распределяются по стойкам. Одна треть реплик находится на одном узле, две трети реплик находятся на одной стойке, а другая треть равномерно распределена по остальным стойкам. Эта политика повышает производительность записи без ущерба для надежности данных или производительности чтения.
Надежность
Основная задача HDFS — надежное хранение данных даже в случае сбоев. Наиболее распространены три типа сбоев: сбои NameNode, сбои DataNode и сетевые разделы.
Отказ диска данных, heartbeat и повторная репликация
Каждый DataNode периодически отправляет сообщение Heartbeat в NameNode. Сетевой раздел может привести к тому, что подмножество DataNode теряет связь с NameNode. NameNode обнаруживает это состояние по отсутствию сообщения Heartbeat. NameNode помечает узлы данных без недавних сообщений как мертвые и не пересылает им новые запросы ввода-вывода. Любые данные, которые были зарегистрированы на мертвом DataNode, больше не доступны для HDFS. Сбой DataNode может привести к тому, что коэффициент репликации некоторых блоков упадет ниже заданного значения. NameNode постоянно отслеживает, какие блоки должны быть реплицированы, и инициирует репликацию при необходимости. Необходимость повторной репликации может возникнуть по многим причинам: узел данных может стать недоступным, реплика может быть повреждена, жесткий диск на узле данных может выйти из строя или коэффициент репликации файла может быть увеличен.
Перебалансировка кластеров
Архитектура HDFS совместима со схемами перебалансировки данных. Схема может автоматически перемещать данные из одного DataNode в другой, если свободное пространство в DataNode падает ниже определенного порога. В случае внезапного высокого спроса на конкретный файл схема может динамически создавать дополнительные реплики и перебалансировать другие данные в кластере. Эти типы схем перебалансировки данных еще не реализованы.
Целостность данных
Возможно, что блок данных, извлеченный из DataNode, прибывает поврежденным. Это повреждение может происходить из-за сбоев в устройстве хранения данных, сбоев сети или ошибок программного обеспечения. Клиентское программное обеспечение HDFS осуществляет проверку контрольной суммы содержимого файлов HDFS. Когда клиент создает файл HDFS, он вычисляет контрольную сумму каждого блока файла и сохраняет эти контрольные суммы в отдельном скрытом файле в том же пространстве имен HDFS. Когда клиент получает содержимое файла, он проверяет, соответствуют ли данные, полученные им от каждого узла данных, контрольной сумме, хранящейся в соответствующем файле контрольной суммы. Если нет, то клиент может выбрать получение этого блока из другого DataNode, который имеет реплику этого блока.
Ошибка метаданных на диске
FsImage и EditLog являются центральными структурами данных HDFS. Повреждение этих файлов может привести к неработоспособности экземпляра HDFS. По этой причине NameNode может быть настроен для поддержки нескольких копий FsImage и EditLog. Любое обновление FsImage или EditLog приводит к тому, что каждый из FsImages и EditLogs обновляется синхронно. Это синхронное обновление нескольких копий FsImage и EditLog может снизить скорость транзакций в секунду, поддерживаемую NameNode. Однако это ухудшение допустимо, поскольку, хотя приложения HDFS по своей природе очень интенсивно используют данные, они не требуют интенсивного использования метаданных. Когда NameNode перезапускается, он выбирает последний совместимый FsImage и EditLog для использования.
Машина NameNode является единственной точкой отказа для кластера HDFS. Если машина NameNode выходит из строя, необходимо ручное вмешательство. В настоящее время автоматический перезапуск и аварийное переключение программного обеспечения NameNode на другой компьютер не поддерживается.
Применение Hadoop Distributed File System
HDFS – неотъемлемая часть Hadoop, проекта верхнего уровня Apache Software Foundation, и основа инфраструктуры больших данных (Big Data). Однако, Hadoop поддерживает работу и с другими распределёнными файловыми системами, в частности, Amazon S3 и CloudStore. Также некоторые дистрибутивы Hadoop, например, MapR, реализуют свою аналогичную распределенную файловую систему – MapR File System .
HDFS может использоваться не только для запуска MapReduce-заданий, но и как распределённая файловая система общего назначения, обеспечивая работу распределённых СУБД (HBase) и масштабируемых систем машинного обучения (Apache Mahout) .
Evaluating a Distributed Lock Manager
This section covers the following topics:
How a DLM Implementation Impacts Oracle
Optimal DLM Features
How a DLM Implementation Impacts Oracle
The features of your system’s DLM will have a noticeable effect on the performance of the Oracle Parallel Server.
Most DLM resources are not deadlock sensitive, but some are.
The time it takes to perform DLM recovery depends on the number of nodes.
If persistent resources are available, you can take advantage of fine grain locking.
Optimal DLM Features
The DLM should be distributed.
The DLM should be fault tolerant.
Lock mastering should be advantageous for your configuration.
Memory usage should be adequate to support the number of resources your application will require.
Deadlock detection should be distributed, for optimal performance. If all deadlock-sensitive locks go to one node, then this will be very slow for the other nodes. (This is less of an issue for small cluster systems.)
Tools should be available to monitor and manage locks with ease.
|
Prev |
Copyright 1996 Oracle Corporation. All Rights Reserved. |
Library | Product | Contents | Index |
Постоянство метаданных файловой системы
Пространство имен HDFS хранится в NameNode. NameNode использует журнал транзакций, называемый EditLog, для постоянной записи каждого изменения, которое происходит с метаданными файловой системы. Например, создание нового файла в HDFS заставляет NameNode вставить запись в EditLog, указывающую на это. Аналогично, изменение коэффициента репликации файла приводит к вставке новой записи в EditLog. NameNode использует файл в своей локальной файловой системе ОС для хранения EditLog. Все пространство имен файловой системы, включая отображение блоков в файлы и свойства файловой системы, хранится в файле с именем FsImage. FsImage также сохраняется в виде файла в локальной файловой системе NameNode.
NameNode хранит изображение всего пространства имен файловой системы и файла Blockmap в памяти. Этот ключевой элемент метаданных спроектирован так, чтобы быть компактным, так что NameNode с 4 ГБ ОЗУ достаточно для поддержки огромного количества файлов и каталогов. Когда NameNode запускается, он считывает FsImage и EditLog с диска, применяет все транзакции из EditLog к представлению FsImage в памяти и сбрасывает эту новую версию в новый FsImage на диске. Затем он может усечь старый EditLog, потому что его транзакции были применены к постоянному FsImage. Этот процесс называется контрольной точкой. В текущей реализации контрольная точка возникает только при запуске NameNode. Ведется работа по поддержке периодической проверки в ближайшем будущем.
DataNode хранит данные HDFS в файлах в своей локальной файловой системе. DataNode не знает о файлах HDFS. Каждый блок данных HDFS хранится в отдельном файле в локальной файловой системе. DataNode не создает все файлы в одном каталоге. Вместо этого он использует эвристику для определения оптимального количества файлов в каталоге и соответствующим образом создает подкаталоги. Не является оптимальным создание всех локальных файлов в одном каталоге, поскольку локальная файловая система может не иметь возможности эффективно поддерживать огромное количество файлов в одном каталоге. Когда DataNode запускается, он просматривает свою локальную файловую систему, генерирует список всех блоков данных HDFS, которые соответствуют каждому из этих локальных файлов, и отправляет этот отчет в NameNode: это Blockreport.
Comparing VMFS to Conventional File Systems
Again from the VMware vStorage Virtual Machine File System Technical Overview and Best Practices, we have some more hints about VMFS:
- Conventional file systems (CFS) allow only one server to have read/write access to a specific file at a given time. In contrast, VMFS is a CFS that leverages shared storage to allow multiple instances of ESX Server to have concurrent read and write access to the same storage resources.
- VMFS also has distributed journaling of changes to the VMFS metadata to enable fast and resilient recovery across these multiple ESX Server clusters.
The VMFS driver is one of the best piece of software VMware developed but does it scale out in a cloud environment?. Remember that the ‘recommended’ limit is still 32 hosts in a VMware Cluster. I can’t believe it is a hard limit, same for datastore maximum size of 2TB. Will VMFS v5 bring us major enhancement in this area?
Before I finish my post here, I wanted to talk about an excellent article of Duncan Epping at Yellow-bricks.com about VMFS format and VMFS driver and their respective abilities.
