|
|
|
|
@ -80,71 +80,67 @@ All other client-side components are based on the client library:
|
|
|
|
|
- **vitastor-disk** — утилита для разметки дисков под Vitastor OSD. С её помощью можно
|
|
|
|
|
создавать, удалять, менять размеры или перемещать разделы OSD.
|
|
|
|
|
|
|
|
|
|
## Overall read/write process
|
|
|
|
|
## Общий процесс записи и чтения
|
|
|
|
|
|
|
|
|
|
- Vitastor stores virtual disks, also named "images" or "inodes".
|
|
|
|
|
- Each image is stored in some pool. Pool specifies storage parameters such as redundancy
|
|
|
|
|
scheme (replication or EC — erasure codes, i.e. error correction codes), failure domain
|
|
|
|
|
and restrictions on OSD selection for image data placement. See [Pool configuration](../config/pool.en.md) for details.
|
|
|
|
|
- Each image is split into objects/blocks of fixed size, equal to [block_size](../config/layout-cluster.en.md#block_size)
|
|
|
|
|
(128 KB by default), multiplied by data part count for EC or 1 for replicas. That is,
|
|
|
|
|
if a pool uses EC 4+2 coding scheme (4 data parts + 2 parity parts), then, with the
|
|
|
|
|
default block_size, images are split into 512 KB objects.
|
|
|
|
|
- Client read/write requests are split into parts at object boundaries.
|
|
|
|
|
- Each object is mapped to a PG number it belongs to, by simply taking a remainder of
|
|
|
|
|
division of its offset by PG count of the image's pool.
|
|
|
|
|
- Client reads primary OSD for all PGs from etcd. Primary OSD for each PG is assigned
|
|
|
|
|
by the monitor during cluster operation, along with the full PG OSD set.
|
|
|
|
|
- If not already connected, client connects to primary OSDs of all PGs involved in a
|
|
|
|
|
read/write request and sends parts of the request to them.
|
|
|
|
|
- If a primary OSD is unavailable, client retries connection attempts indefinitely
|
|
|
|
|
either until it becomes available or until the monitor assigns another OSD as primary
|
|
|
|
|
for that PG.
|
|
|
|
|
- Client also retries requests if the primary OSD replies with error code EPIPE, meaning
|
|
|
|
|
that the PG is inactive at this OSD at the moment - for example, when the primary OSD
|
|
|
|
|
is switched, or if the primary OSD itself loses connection to replicas during request
|
|
|
|
|
handling.
|
|
|
|
|
- Primary OSD determines where the parts of the object are stored. By default, all objects
|
|
|
|
|
are assumed to be stored at the target OSD set of a PG, but some of them may be present
|
|
|
|
|
at a different OSD set if they are degraded or moved, or if the data rebalancing process
|
|
|
|
|
is active. OSDs doesn't do any network requests, if calculates locations of all objects
|
|
|
|
|
during PG activation and stores it in memory.
|
|
|
|
|
- Primary OSD handles the request locally when it can - for example, when it's a read
|
|
|
|
|
from a replicated pool or when it's a read from a EC pool involving only one data part
|
|
|
|
|
stored on the OSD's local disk.
|
|
|
|
|
- When a request requires reads or writes to additional OSDs, primary OSD uses already
|
|
|
|
|
established connections to secondary OSDs of the PG to execute these requests. This happens
|
|
|
|
|
in parallel to local disk operations. All such connections are guaranteed to be already
|
|
|
|
|
established when the PG is active, and if any of them is dropped, PG is restarted and
|
|
|
|
|
all current read/write operations to it fail with EPIPE error and are retried by clients.
|
|
|
|
|
- After completing all secondary read/write requests, primary OSD sends the response to
|
|
|
|
|
the client.
|
|
|
|
|
- В Vitastor хранятся виртуальные диски, также называемые "образы" или "иноды".
|
|
|
|
|
- Каждый образ хранится в определённом пуле. Пул определяет параметры хранения образов в нём,
|
|
|
|
|
такие, как схему избыточности (репликация или EC — коды коррекции ошибок), домен отказа
|
|
|
|
|
и ограничения по выбору OSD для размещения данных образов. См. [Конфигурация пулов](../config/pool.ru.md).
|
|
|
|
|
- Каждый образ разбивается на объекты фиксированного размера, равного [block_size](../config/layout-cluster.ru.md#block_size)
|
|
|
|
|
(по умолчанию 128 КБ), умноженному на число частей данных для EC или на 1 для реплик.
|
|
|
|
|
То есть, например, если в пуле используется схема кодирования 4+2 (4 части данных + 2 чётности),
|
|
|
|
|
то при стандартном block_size образы разбиваются на части по 512 КБ.
|
|
|
|
|
- Клиентские запросы чтения/записи разделяются на части, соответствующие этим объектам.
|
|
|
|
|
- Для каждого объекта определяется номер PG, которой он принадлежит, путём простого взятия
|
|
|
|
|
остатка от деления ID образа и смещения на число PG в пуле, которому принадлежит образ.
|
|
|
|
|
- Клиент читает информацию о первичном OSD всех PG из etcd. Первичный OSD каждой PG назначается
|
|
|
|
|
монитором в процессе работы кластера, вместе с текущим целевым набором OSD этой PG.
|
|
|
|
|
- Клиент соединяется (если ещё не соединён) с первичными OSD всех PG, объекты которых участвуют
|
|
|
|
|
в запросе и одновременно отправляет им запросы чтения/записи частей.
|
|
|
|
|
- Если какие-то из первичных OSD недоступны, клиент повторяет попытки соединения бесконечно до
|
|
|
|
|
тех пор, пока они не станут доступны или пока PG не будут назначены другие первичные OSD.
|
|
|
|
|
- Клиент также повторяет запросы, если первичные OSD отвечают кодом ошибки EPIPE, означающим,
|
|
|
|
|
что запрос не может быть обработан в данный момент. Это происходит, если PG либо не активна
|
|
|
|
|
вообще, либо не активна на данном OSD в данный момент (например, если в этот момент меняется
|
|
|
|
|
её первичный OSD) или если в процессе обработки запроса сам первичный OSD теряет подключение
|
|
|
|
|
к репликам.
|
|
|
|
|
- Первичный OSD определяет, на каких OSD находятся части объекта. По умолчанию все объекты
|
|
|
|
|
считаются находящимися на текущем целевом наборе OSD соответствующей PG, но какие-то могут
|
|
|
|
|
находиться на других OSD, если эти объекты деградированы или перемещены, или идёт процесс
|
|
|
|
|
ребаланса. Запросы для проверки по сети не отправляются, информация о местоположении всех
|
|
|
|
|
объектов рассчитывается первичным OSD при активации PG и хранится в памяти.
|
|
|
|
|
- Первичный OSD соединяется (если ещё не соединён) с вторичными OSD, на которых располагаются
|
|
|
|
|
части объекта, и отправляет им запросы чтения/записи, а также читает/пишет из/в своё локальное
|
|
|
|
|
хранилище, если сам входит в набор.
|
|
|
|
|
- После завершения всех вторичных операций чтения/записи первичный OSD отправляет ответ клиенту.
|
|
|
|
|
|
|
|
|
|
### Nuances of request handling
|
|
|
|
|
### Особенности обработки запросов
|
|
|
|
|
|
|
|
|
|
- If a pool uses erasure codes and some of the OSDs are unavailable, primary OSDs recover
|
|
|
|
|
data from the remaining parts during read.
|
|
|
|
|
- Each object has a version number. During write, primary OSD first determines the current
|
|
|
|
|
version of the object. As primary OSD usually stores the object or its part itself, most
|
|
|
|
|
of the time version is read from the memory of the OSD itself. However, if primary OSD
|
|
|
|
|
doesn't contain parts of the object, it requests the version number from a secondary OSD
|
|
|
|
|
which has that part. Such request still doesn't involve reading from the disk though,
|
|
|
|
|
because object metadata, including version number, is always stored in OSD memory.
|
|
|
|
|
- If a pool uses erasure codes, partial writes of an object require reading other parts of
|
|
|
|
|
it from secondary OSDs or from the local disk of the primary OSD itself. This is called
|
|
|
|
|
"read-modify-write" process.
|
|
|
|
|
- If a pool uses erasure codes, two-phase write process is used to get rid of the Write Hole
|
|
|
|
|
problem: first a new version of object parts is written to all secondary OSDs without
|
|
|
|
|
removing the previous version, and then, after receiving successful write confirmations
|
|
|
|
|
from all OSDs, new version is committed and the old one is allowed to be removed.
|
|
|
|
|
- In a pool doesn't use immediate_commit mode, then write requests sent by clients aren't
|
|
|
|
|
treated as committed to physical media instantly. Clients have to send separate type of
|
|
|
|
|
requests (SYNC) to commit changes, and before it isn't sent, new versions of data are
|
|
|
|
|
allowed to be lost if some OSDs die. Thus, when immediate_commit is disabled, clients
|
|
|
|
|
store copies of all write requests in memory and repeat them from there when the
|
|
|
|
|
connection to primary OSD is lost. This in-memory copy is removed after a successful
|
|
|
|
|
SYNC, and to prevent excessive memory usage, clients also do an automatic SYNC
|
|
|
|
|
every [client_dirty_limit](../config/network.en.md#client_dirty_limit) written bytes.
|
|
|
|
|
- Если в пуле используются коды коррекции ошибок и при этом часть OSD недоступна, первичный
|
|
|
|
|
OSD при чтении восстанавливает данные из оставшихся частей.
|
|
|
|
|
- Каждый объект имеет номер версии. При записи объекта первичный OSD сначала читает из номер
|
|
|
|
|
версии объекта. Так как первичный OSD обычно сам хранит копию или часть объекта, номер
|
|
|
|
|
версии обычно читается из памяти самого OSD. Однако, если ни одна часть обновляемого объекта
|
|
|
|
|
не находится на первичном OSD, для получения номера версии он обращается к одному из вторичных
|
|
|
|
|
OSD, на которых копия объекта есть. Обращения к диску при этом всё равно не происходит,
|
|
|
|
|
так как метаданные объектов, включая номер версии, все OSD хранят в памяти.
|
|
|
|
|
- Если в пуле используются коды коррекции ошибок, перед частичной записью объекта для вычисления
|
|
|
|
|
чётности зачастую требуется чтение частей объекта с вторичных OSD или с локального диска
|
|
|
|
|
самого первичного OSD.
|
|
|
|
|
- Также, если в пуле используются коды коррекции ошибок, для закрытия Write Hole применяется
|
|
|
|
|
двухфазный алгоритм записи: сначала на все вторичные OSD записывается новая версия частей
|
|
|
|
|
объекта, но при этом старая версия не удаляется, а потом, после получения подтверждения
|
|
|
|
|
успешной записи от всех вторичных OSD, новая версия фиксируется и разрешается удаление старой.
|
|
|
|
|
- Если в кластере не включён режим immediate_commit, то запросы записи, отправляемые клиентами,
|
|
|
|
|
не считаются зафиксированными на физических накопителях сразу. Для фиксации данных клиенты
|
|
|
|
|
должны отдельно отправлять запросы SYNC (отдельный от чтения и записи вид запроса),
|
|
|
|
|
а пока такой запрос не отправлен, считается, что записанные данные могут исчезнуть,
|
|
|
|
|
если соответствующий OSD упадёт. Поэтому, когда режим immediate_commit отключён, все
|
|
|
|
|
запросы записи клиенты копируют в памяти и при потере соединения и повторном соединении
|
|
|
|
|
с OSD повторяют из памяти. Скопированные в память данные удаляются при успешном fsync,
|
|
|
|
|
а чтобы хранение этих данных не приводило к чрезмерному потреблению памяти, клиенты
|
|
|
|
|
автоматически выполняют fsync каждые [client_dirty_limit](../config/network.ru.md#client_dirty_limit)
|
|
|
|
|
записанных байт.
|
|
|
|
|
|
|
|
|
|
## Similarities to Ceph
|
|
|
|
|
|
|
|
|
|
|
Vitaliy Filippov