diff --git a/ydb/docs/ru/core/concepts/_assets/storage.drawio b/ydb/docs/ru/core/concepts/_assets/storage.drawio new file mode 100644 index 000000000000..e6f6d15256a1 --- /dev/null +++ b/ydb/docs/ru/core/concepts/_assets/storage.drawio @@ -0,0 +1,114 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/ydb/docs/ru/core/concepts/_assets/storage.png b/ydb/docs/ru/core/concepts/_assets/storage.png new file mode 100644 index 000000000000..67e81dabf520 Binary files /dev/null and b/ydb/docs/ru/core/concepts/_assets/storage.png differ diff --git a/ydb/docs/ru/core/concepts/architecture.md b/ydb/docs/ru/core/concepts/architecture.md index 5a972060acba..72300a59d454 100644 --- a/ydb/docs/ru/core/concepts/architecture.md +++ b/ydb/docs/ru/core/concepts/architecture.md @@ -92,9 +92,13 @@ Data shard также автоматически разделяются при ### Внутреннее устройство распределенного хранилища -![Внутреннее устройство распределенного хранилища](https://storage.yandexcloud.net/ydb-www-prod-site-assets/howitworks/distributed.png) +![Внутреннее устройство распределенного хранилища](./_assets/storage.png) -{{ ydb-short-name }} не полагается на сторонние файловые системы. Она хранит данные, работая непосредственно с дисковыми накопителями как блочными устройствами. Поддерживаются все основные типы дисков: NVMe, SSD или HDD. За работу с конкретным блочным устройством отвечает компонент PDisk. Уровень абстракции выше PDisk называется VDisk. Также есть специальный компонент, называемый DSProxy, между таблеткой и VDisk. DSProxy анализирует доступность и характеристики дисков и выбирает, какие диски будут обрабатывать запрос, а какие нет. +{{ ydb-short-name }} не полагается на сторонние файловые системы. Вместо этого она работает непосредственно с дисковыми накопителями как с блочными устройствами. Поддерживаются различные типы дисков: NVMe, SSD и HDD — подробнее об этом можно узнать в [системных требованиях](../devops/concepts/system-requirements.md). За работу с конкретным блочным устройством отвечает компонент [PDisk](./glossary.md#pdisk), который взаимодействует непосредственно с физическим диском. Уровень абстракции выше PDisk называется [VDisk](./glossary.md#vdisk). + +Между VDisk и компонентами, непосредственно работающими с данными приложений, существует еще один слой абстракции — [Storage Group](./glossary.md#storage-group). Storage Group объединяет несколько VDisk'ов между собой и обеспечивает необходимые [режимы записи данных](./topology.md#cluster-config) для отказоустойчивости. + +Входной точкой в распределённое хранилище является [DS-Proxy](./glossary.md#ds-proxy) (distributed storage proxy). DS-Proxy скрывает распределённую природу хранилища и позволяет таблеткам записывать и читать данные, не заботясь о деталях взаимодействия с VDisk и Storage Group. ### Прокси распределенного хранилища (DSProxy) diff --git a/ydb/docs/ru/core/concepts/glossary.md b/ydb/docs/ru/core/concepts/glossary.md index 8777625e466a..1a3fe54802b5 100644 --- a/ydb/docs/ru/core/concepts/glossary.md +++ b/ydb/docs/ru/core/concepts/glossary.md @@ -58,6 +58,8 @@ [Распределённое хранилище](#distributed-storage) обычно управляет большим количеством относительно небольших групп хранения. Каждую группу можно назначить конкретной [базе данных](#database) для увеличения ёмкости дискового пространства и пропускной способности ввода/вывода, доступных для этой базы данных. +[Статические](#static-group) и [динамические](#dynamic-group) группы хранения являются физическими, то есть их данные размещаются непосредственно на [VDisk'ах](#vdisk) + #### Статическая группа {#static-group} **Статическая группа** или **static group** — это специальная [группа хранения](#storage-group), созданная во время изначального развёртывания кластера. Её основная роль заключается в хранении данных системных [таблеток](#tablet), которые можно рассматривать как метаданные уровня всего кластера. @@ -68,6 +70,10 @@ Обычные группы хранения, которые не являются [статическими](#static-group), называются **динамическими группами** или **dynamic group**. Их называют динамическими, потому что они могут быть созданы и удалены на лету во время работы [кластера](#cluster). +#### Виртуальная группа хранения {#virtual-storage-groups} + +**Виртуальная группа хранения** или **virtual storage group** — это сущность, которая фактически не является [группой хранения](#storage-group), но со стороны выглядит таковой (предоставляет аналогичный внешний интерфейс). Может хранить свои данные в других группах хранения или в S3. + ### Пул хранения {#storage-pool} **Пул хранения** или **storage pool** — это набор устройств хранения данных со схожими характеристиками. Каждому пулу хранения присваивается уникальное имя в рамках кластера {{ ydb-short-name }}. Технически, каждый пул хранения состоит из множества физических дисков ([PDisk](#pdisk)). Каждая [группа хранения](#storage-group) создаётся в определённом пуле хранения, который определяет характеристики производительности группы хранения через выбор соответствующих устройств хранения. Обычно отдельные пулы хранения создают для устройств разных типов (например, NVMe, SSD и HDD) или для конкретных моделей этих устройств, обладающих различной ёмкостью и скоростью доступа. @@ -130,7 +136,7 @@ #### Pile {#pile} -**Pile** или **пайл** — это набор узлов, которые могут отказать или быть отключены одновременно с сохранением работоспособности других частей кластера (pile). Pile может сохранять работоспособность при одключении других узлов кластера. Pile используются в [режиме bridge](#bridge) для разделения кластера на несколько частей, между которыми осуществляется синхронная репликация. Pile может состоять из узлов одного или нескольких регионов. +**Pile** или **пайл** — это набор узлов, которые могут отказать или быть отключены одновременно с сохранением работоспособности других частей кластера (pile). Pile может сохранять работоспособность при отключении других узлов кластера. Pile используются в [режиме bridge](#bridge) для разделения кластера на несколько частей, между которыми осуществляется синхронная репликация. Pile может состоять из узлов одного или нескольких регионов. #### Режим bridge {#bridge} @@ -479,7 +485,7 @@ SID идентифицирует индивидуального [пользов **Реплика таблетки**, **горячий резерв**, **tablet follower** или **hot standby** — это копия [лидера таблетки](#tablet-leader), которая применяет журнал команд, принятых лидером (с некоторой задержкой). У таблетки может быть ноль или больше реплик. Реплики выполняют две основные функции: * В случае завершения или отказа лидера, реплики являются предпочтительными [кандидатами](#tablet-candidate) на роль нового лидера, так как они могут стать лидером намного быстрее, чем другие кандидаты, поскольку они применили большую часть журнала. -* Реплики могут отвечать на запросы только для чтения, если клиент явно выбирает опциональный расслабленных режим транзакций, допускающий устаревшие чтения (stale reads). +* Реплики могут отвечать на запросы только для чтения, если клиент явно выбирает опциональный расслабленный режим транзакций, допускающий устаревшие чтения (stale reads). ### Поколение таблетки {#tablet-generation} @@ -577,8 +583,6 @@ SID идентифицирует индивидуального [пользов #### NodeBroker {#node-broker} -**NodeBroker** — системная таблетка, отвечающая за регистрацию [динамических узлов](#dynamic) в кластере. - **NodeBroker** — это системная таблетка, которая отвечает за регистрацию [динамических узлов](#dynamic) в кластере. #### BSController {#ds-controller} @@ -688,7 +692,7 @@ SID идентифицирует индивидуального [пользов #### Кодирование с исправлением ошибок {#erasure-coding} -[**Кодирование с исправлением ошибок**](https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B8%D1%80%D0%B0%D1%8E%D1%89%D0%B8%D0%B9_%D0%BA%D0%BE%D0%B4) или **erasure coding** — это метод кодирования данных, при котором исходные данные дополняются избыточностью и разделяются на несколько фрагментов, обеспечивая возможность восстановления исходных данных в случае потери одного или нескольких фрагментов. Он широко используется в кластерах {{ ydb-short-name }} с одной [зоной доступности](#regions-az) в отличии от [репликации](#replication) с 3 репликами. Например, наиболее популярная схема erasure coding 4+2 обеспечивает ту же надёжность, что и три реплики, с избыточностью пространства 1.5 против 3. +[**Кодирование с исправлением ошибок**](https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B8%D1%80%D0%B0%D1%8E%D1%89%D0%B8%D0%B9_%D0%BA%D0%BE%D0%B4) или **erasure coding** — это метод кодирования данных, при котором исходные данные дополняются избыточностью и разделяются на несколько фрагментов, обеспечивая возможность восстановления исходных данных в случае потери одного или нескольких фрагментов. Он широко используется в кластерах {{ ydb-short-name }} с одной [зоной доступности](#regions-az) в отличие от [репликации](#replication) с 3 репликами. Например, наиболее популярная схема erasure coding 4+2 обеспечивает ту же надёжность, что и три реплики, с избыточностью пространства 1.5 против 3. #### PDisk {#pdisk}