Blobstorage configuration

updated

Fix some typos

Some thoughts on production storage configuration,

4 files changed, 82 insertions, 1 deletions

diff --git a/ydb/docs/ru/core/administration/production-storage-config.md b/ydb/docs/ru/core/administration/production-storage-config.md
new file mode 100644
index 0000000000..d476eae3cf
--- /dev/null
+++ b/ydb/docs/ru/core/administration/production-storage-config.md
@@ -0,0 +1,78 @@
+# Промышленные конфигурации BlobStorage
+
+Для обеспечения необходимой отказоустойчивости {{ ydb-short-name }} нужно правильно сконфигурировать [дисковую подсистему кластера](../concepts/cluster/distributed_storage.md): выбрать подходящий [режим отказоустойчивости](#fault-tolerance) и [аппаратную конфигурацию](#requirements) кластера.
+
+## Режимы отказоустойчивости {#fault-tolerance}
+
+Для промышленных инсталляций {{ ydb-short-name }} рекомендуется использовать следующие [режимы отказоустойчивости](../cluster/topology.md):
+
+* `block-4-2` — если кластер расположен в одной зоне доступности.
+* `mirror-3-dc` — если кластер расположен в трех зонах доступности.
+
+В модели отказа {{ ydb-short-name }} различаются понятия домена отказа и области отказа.
+
+Домен отказа (fail domain)
+
+: Набор оборудования, для которого вероятен одновременный отказ.
+
+  Например, доменом отказа можно считать диски одного сервера (в связи с вероятной недоступностью всех дисков сервера при отказе блока питания или сетевого контроллера сервера). Также доменом отказа можно считать серверы, расположенные в одной серверной стойке (в связи с вероятной недоступностью всего оборудования в стойке при проблемах с питанием или сетевым оборудованием, расположенным в той же стойке).
+
+  Обработка любых отказов домена осуществляется автоматически, без остановки работы системы.
+
+Область отказа (fail realm)
+
+: Набор доменов отказа, для которого вероятен одновременный отказ.
+
+  Например, областью отказа можно считать оборудование, расположенное в одном центре обработки данных (ЦОД), который может выйти из строя в результате стихийного бедствия.
+
+Обычно под доменом отказа подразумевается серверная стойка, а под областью отказа – ЦОД.
+
+При создании [групп хранения](../concepts/databases.md#storage-groups) {{ ydb-short-name }} объединяет в группы VDisk, расположенные на PDisk из разных доменов отказа. Таким образом, для режима `block-4-2` необходимо распределение PDisk по не менее чем 8 доменам отказа, а для режима `mirror-3-dc` — по 3 областям отказа с не менее чем 3 доменами отказа в каждой.
+
+## Аппаратная конфигурация {#requirements}
+
+При отказе диска {{ ydb-short-name }} может автоматически переконфигурировать группу хранения так, чтобы вместо расположенного на отказавшем оборудовании VDisk использовался новый VDisk, который система пытается расположить на работающем в момент реконфигурации оборудовании. При этом соблюдается то же правило, что и при создании группы — VDisk создается в домене отказа, отличном от доменов отказа всех остальных VDisk этой группы (и в той же области отказа, что и отказавший VDisk для `mirror-3-dc`).
+
+Это вызывает ряд проблем в случе, когда оборудование кластера распределено по минимально необходимому количеству доменов отказа:
+
+* при отказе всего домена реконфигурация теряет смысл т.к. новый VDisk может быть расположен только в отказавшем домене отказа;
+* при отказе части домена реконфигурация возможна, но при этом нагрузка, которая раньше обрабатывалась отказавшим оборудованием будет перераспределена только по оборудованию в том же домене отказа.
+
+Если же в кластере доступно хотя бы на 1 домен отказа больше, чем минимально необходимо для создания групп хранения (9 доменов для `block-4-2` и по 4 домена в каждой области отказа для `mirror-3-dc)`, то при отказе части оборудования нагрузка может быть перераспределена по всему оставшемуся в строю оборудованию.
+
+Система может работать с доменами отказа любого размера, однако при малом количестве доменов и неодинаковом количестве дисков в разных доменах количество групп хранения, которые возможно будет создать, окажется ограничено. При этом часть оборудования в слишком больших доменах отказа может оказаться недоутилизированной. В случае полной утилизации оборудования существенный перекос в размерах доменов может сделать невозможной реконфигурацию.
+
+>Например, в кластере с режимом отказоустойчивости `block-4-2` имеется 15 стоек. В первой из 15 стоек расположено 20 серверов, а в остальных 14 стойках — по 10. Для полноценной утилизации всех 20 серверов из первой стойки {{ ydb-short-name }} будет создавать группы так, что в каждой из них будет участвовать 1 диск из этого самого большого домена отказа. В результате при выходе из строя оборудования в любом другом домене отказа нагрузка не сможет быть распределена на оборудование в первой стойке.
+
+{{ ydb-short-name }} может объединять в группу диски разных производителей, различной емкости и скорости. Результирующие характеристики группы определяются набором наихудших характеристик оборудования, которое ее обслуживает. Обычно лучших результатов удается добиться при использовании однотипного оборудования. При создании больших кластеров следует учитывать и то, что оборудование из одной партии с большей вероятностью может иметь одинаковый дефект и отказать одновременно.
+
+Таким образом, в качестве оптимальных аппаратных конфигураций для промышленного применения рекомендуются следующие:
+
+* **Кластер в 1 зоне доступности** — использует режим отказоустойчивости `block4-2` и состоит из 9 или более стоек с равным количеством одинаковых серверов в каждой.
+* **кластер в 3 зонах доступности** — использует режим отказоустойчивости `mirror3-dc` и  расположен в 3 ЦОД с 4 или более стойками в каждом, стойки укомплектованы равным количеством одинаковых серверов.
+
+Смотрите также [{#T}](#reduced).
+
+## Восстановление избыточности {#rebuild}
+
+Автоматическая реконфигурация групп хранения снижает вероятность потери данных при возникновении множественных отказов, возникающих с достаточными для завершения восстановления избыточности интервалами. По умолчанию реконфигурация происходит через 1 час после того, как {{ ydb-short-name }} выявляет отказ.
+
+После реконфигурации новый VDisk автоматически наполняется данными для восстановления требуемой избыточности хранения в группе. При этом возникает повышенная нагрузка на остальные VDisk группы и на сеть. Для снижения влияния восстановления избыточности на производительность системы суммарная скорость репликации данных ограничивается как на стороне VDisk-источника так и на стороне VDisk-получателя.
+
+Время восстановления избыточности при этом зависит от объема данных и от производительности оборудования. Например, репликация на быстрых NVMe SSD может завершиться за час, а на больших HDD репликация может длиться более суток.  Для того, чтобы реконфигурация в принципе была возможной, в кластере должны быть свободные слоты для создания VDisk в разных доменах отказа. При расчете количества оставляемых свободными слотов следует учитывать вероятность отказа оборудования, длительность репликации, время, необходимое на замену отказавшего оборудования.
+
+## Упрощенные аппаратные конфигурации {#reduced}
+
+В случаях, когда невозможно использовать [рекомендованное количество](#requirements) оборудования, можно разделить серверы одной стойки на 2 фиктивных домена отказа. В такой конфигурации отказ 1 стойки будет означать отказ не 1, а сразу 2 доменов. В [обоих режимах](#fault-tolerance) отказоустойчивости {{ ydb-short-name }} сохранит работоспособность при отказе 2 доменов. При использовании конфигурации с фиктивными доменами отказа минимальное количество стоек в кластере для режима `block-4-2` составляет 5, для `mirror-3-dc` — по 2 в каждом ЦОД.
+
+## Уровень отказоустойчивости {#reliability}
+
+В таблице приведены уровни отказоустойчивости для различных режимов отказоустойчивости и аппаратных конфигураций кластера {{ ydb-short-name }}:
+
+Режим<br>отказоустойчивости | Домен<br>отказа | Область<br>отказа | Количество<br>ЦОД | Количество<br>серверных стоек | Уровень<br>отказоустойчивости
+:--- | :---: | :---: | :---: | :---: | :---
+`block-4-2` | Стойка | ЦОД | 1 | 9 или более | Переживает отказ 2 стоек
+`block-4-2` | ½ стойки | ЦОД | 1 | 5 или более | Переживает отказ 1 стойки
+`block-4-2` | Сервер | ЦОД | 1 | Не важно | Переживает отказ 2 серверов
+`mirror-3-dc` | Стойка | ЦОД | 3 | По 4 в каждом ЦОД | Переживает отказ ЦОД и 1 стойки в одном из двух других ЦОД
+`mirror-3-dc` | Сервер | ЦОД | 3 | Не важно | Переживает отказ ЦОД и 1 сервера в одном из двух других ЦОД
diff --git a/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/distributed_storage_interface.md b/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/distributed_storage_interface.md
index 305da56bab..f024b59bbf 100644
--- a/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/distributed_storage_interface.md
+++ b/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/distributed_storage_interface.md
@@ -25,7 +25,7 @@
 
 Запись блобов производится в логическую сущность, называемую *группой*. На каждом узле для каждой группы, в которую осуществляется запись, создается специальный актор, который называется DS proxy. Этот актор отвечает за выполнение всех операций, связанных с группой. Создание этого актора производится автоматически через сервис NodeWarden, о котором речь пойдет ниже.
 
-Физически группа представляет собой набор из нескольких физических устройств (блочные устройства в ОС), которые расположены на разных узлах таким образом, чтобы выход из строя одного устройства как можно меньше коррелировал с выходом из строя другого устройства; как правило, эти устройства располагаются в разных стойках или в разных ДЦ. На каждом из этих устройств для группы выделено место, которое управляется специальным сервисом, который называется *VDisk*. Каждый VDisk работает поверх блочного устройства, от которого он отделен другим сервисом — *PDisk*. Блобы разбиваются на фрагменты в соответствии с *erasure-кодированием*, на VDisk'и пишутся строго фрагменты. Перед разбиванием на фрагменты может выполняться опциональное шифрование данные в группе.
+Физически группа представляет собой набор из нескольких физических устройств (блочные устройства в ОС), которые расположены на разных узлах таким образом, чтобы выход из строя одного устройства как можно меньше коррелировал с выходом из строя другого устройства; как правило, эти устройства располагаются в разных стойках или в разных ДЦ. На каждом из этих устройств для группы выделено место, которое управляется специальным сервисом, который называется *VDisk*. Каждый VDisk работает поверх блочного устройства, от которого он отделен другим сервисом — *PDisk*. Блобы разбиваются на фрагменты в соответствии с [erasure-кодированием](https://ru.wikipedia.org/wiki/Стирающий_код), на VDisk'и пишутся строго фрагменты. Перед разбиванием на фрагменты может выполняться опциональное шифрование данные в группе.
 
 Схематично это показано на рисунке ниже.
 
diff --git a/ydb/docs/ru/core/deploy/_includes/index.md b/ydb/docs/ru/core/deploy/_includes/index.md
index 56a25f34a7..4d80c84680 100644
--- a/ydb/docs/ru/core/deploy/_includes/index.md
+++ b/ydb/docs/ru/core/deploy/_includes/index.md
@@ -7,5 +7,6 @@
 * [Развертывание в Kubernetes](../orchestrated/concepts.md).
 * [Развертывание на виртуальных и железных серверах](../manual/deploy-ydb-on-premises.md).
 * [Конфигурирование](../configuration/config.md).
+- [Промышленные конфигурации BlobStorage](../../administration/production-storage-config.md).
 
 Пошаговые сценарии быстрого развертывания локального одноузлового кластера для целей разработки и тестирования функциональности приведены в разделе [Начало работы](../../getting_started/self_hosted/index.md).
diff --git a/ydb/docs/ru/core/deploy/toc_i.yaml b/ydb/docs/ru/core/deploy/toc_i.yaml
index d36876a9b4..cc0715cf46 100644
--- a/ydb/docs/ru/core/deploy/toc_i.yaml
+++ b/ydb/docs/ru/core/deploy/toc_i.yaml
@@ -5,4 +5,6 @@ items:
   href: manual/deploy-ydb-on-premises.md
 - name: Конфигурация
   href: configuration/config.md
+- name: Промышленные конфигурации BlobStorage
+  href: ../administration/production-storage-config.md