Change terms to VDisk and PDisk, KIKIMR-13082

ref:2d462f1a2d7f229ae995b0373852ba1b14da0ebb

10 files changed, 58 insertions, 60 deletions

diff --git a/ydb/docs/ru/core/maintenance/embedded_monitoring/ydb_monitoring.md b/ydb/docs/ru/core/maintenance/embedded_monitoring/ydb_monitoring.md
index 1788b843dc..172480a081 100644
--- a/ydb/docs/ru/core/maintenance/embedded_monitoring/ydb_monitoring.md
+++ b/ydb/docs/ru/core/maintenance/embedded_monitoring/ydb_monitoring.md
@@ -111,14 +111,14 @@ http://<ендпоинт>:8765/monitoring/node/<node-id>/
 
 * ID группы хранения;
 * индикатор быстродействия группы;
-* количество вдисков в группе;
+* количество VDisk'ов в группе;
 * топология хранения данных.
 
-Каждую группу хранения также можно раскрыть в список вдисков, где для каждого вдиска приведены:
+Каждую группу хранения также можно раскрыть в список VDisk'ов, где для каждого VDisk'а приведены:
 
-* ID вдиска;
-* уникальный в пределах узла ID блочного устройства на котором находится вдиск;
-* ID узла на котором находится вдиск;
+* VDiskID;
+* уникальный в пределах узла PDiskID на котором находится VDisk;
+* ID узла на котором находится VDiks;
 * свободное/досупное место на блочном устройстве;
 * путь используемый для доступа к блочнму устройству.
 
@@ -164,7 +164,7 @@ http://<ендпоинт>:8765/monitoring/tenant/healthcheck?name=<tenant-path>
 На странице тенанта так же имеются следующие вкладки:
 
 * **HealthCheck** — отчет о проблемах кластера при их наличии;
-* **Storage** — [список групп хранения](#tenant_storage_page), содержит информацию о том какие вдиски на каких узлах и устройствах работают;
+* **Storage** — [список групп хранения](#tenant_storage_page), содержит информацию о том какие VDisk'и на каких узлах и устройствах работают;
 * **Compute** — [список узлов](#tenant_compute_page), содержит узлы и таблетки запущенные на них;
 * **Schema** — [схема тенанта](#tenant_scheme), позвляет просматривать таблицы, выполнять YQL запросы, проосматривать перечень самых медленные запросов и самых нагруженных шардов;
 * **Network** — [состояние сети кластера](#tenant_network).
diff --git a/ydb/docs/ru/core/maintenance/manual/cluster_decomision.md b/ydb/docs/ru/core/maintenance/manual/_includes/cluster_decomision.md
index fe579e72e6..fe579e72e6 100644
--- a/ydb/docs/ru/core/maintenance/manual/cluster_decomision.md
+++ b/ydb/docs/ru/core/maintenance/manual/_includes/cluster_decomision.md
diff --git a/ydb/docs/ru/core/maintenance/manual/balancing_load.md b/ydb/docs/ru/core/maintenance/manual/balancing_load.md
index 00e42e4671..dc97122bf9 100644
--- a/ydb/docs/ru/core/maintenance/manual/balancing_load.md
+++ b/ydb/docs/ru/core/maintenance/manual/balancing_load.md
@@ -6,13 +6,13 @@
 
 На странице [web-мониторинга хайва](../embedded_monitoring/hive.md#reassign_groups), в нижней части экрана есть кнокпа "Reassign Groups".
 
-## Разложить вдиски равномерно по устройствам
+## Разложить VDisk'и равномерно по устройствам
 
-В случае, если вдиски расположены на блочных устройствах не равномерно, можно [перевезти их](moving_vdisks.md#moving_vdisk) по одному с перегруженных устройств.
+В случае, если VDisk'и расположены на блочных устройствах не равномерно, можно [перевезти их](moving_vdisks.md#moving_vdisk) по одному с перегруженных устройств.
 
-## Изменение количествa слотов для вдисков на пдисках
+## Изменение количествa слотов для VDisk'ов на PDisk'ах
 
-Для добавления групп хранения требуется переопределить конфиг хоста, увеличив для него количество слотов на дисках.
+Для добавления групп хранения требуется переопределить конфиг хоста, увеличив для него количество слотов на PDisk'ах.
 
 Перед этим требуется получить изменяемые конфиг, это можно сделать следующей командой:
 
diff --git a/ydb/docs/ru/core/maintenance/manual/disk_end_space.md b/ydb/docs/ru/core/maintenance/manual/disk_end_space.md
index 152c9a97be..397bab4d43 100644
--- a/ydb/docs/ru/core/maintenance/manual/disk_end_space.md
+++ b/ydb/docs/ru/core/maintenance/manual/disk_end_space.md
@@ -4,28 +4,28 @@
 
 Ниже приведены инструкции которые могут помочь добавить или освободить место на дисках.
 
-## Дефрагменировать вдиск
+## Дефрагменировать VDisk
 
-В ходе эксплуатации возникает внутренняя фрагментация вдиска. Узнать степень фрагментации можно на странице мониторинга вдиска. Дефрагментация дисков, фрагментированных на 20 и менее процентов не рекомендуется.
+В ходе эксплуатации возникает внутренняя фрагментация VDisk'а. Узнать степень фрагментации можно на странице мониторинга VDisk'а. Дефрагментация VDisk'ов, фрагментированных на 20 и менее процентов не рекомендуется.
 
-По модели отказа кластер переживает потерю двух вдисков одной группы без потери данных. Если в группе все вдиски работоспособны, нет вдисков в состоянии ошибки или репликации, удаление данных с одного из вдисков приведет к восстановлению вдиском данных в компактном виде. Следует понимать, что избыточность хранения данных будет снижена до завершения автоматической репликации данных.
+По модели отказа кластер переживает потерю двух VDisk'ов одной группы без потери данных. Если в группе все VDisk'и работоспособны, нет VDisk'ов в состоянии ошибки или репликации, удаление данных с одного из VDisk'ов приведет к восстановлению VDisk'ом данных в компактном виде. Следует понимать, что избыточность хранения данных будет снижена до завершения автоматической репликации данных.
 
-В процессе репликации данных нагрузка на все вдиски группы будет увеличена, возможно ухудшение времени отклика.
+В процессе репликации данных нагрузка на все VDisk'и группы будет увеличена, возможно ухудшение времени отклика.
 
-1. Посмотреть коэффициент фрагментации на странице вдиска во вьювере (ссылка).
+1. Посмотреть коэффициент фрагментации на странице VDisk'а во вьювере (ссылка).
 
-   Если значение превышает 20%, то дефрагментация позволит освободить место на диске.
+   Если значение превышает 20%, то дефрагментация позволит освободить место на VDisk'е.
 
-2. Проверить состояние группы в которую входит вдиск. В группе не должно быть недосупных вдисков, вдисков в состоянии ошибки или репликации.
+2. Проверить состояние группы в которую входит VDisk. В группе не должно быть недосупных VDisk'ов, VDisk'ов в состоянии ошибки или репликации.
 
     Посмотреть состояние группые можно во вьювере (ссылка).
 
-3. Выполнить команду wipe для вдиска.
+3. Выполнить команду wipe для VDisk'а.
 
-    Все данные хранимые вдиском будут необратимо удалены, после чего вдиск начнет восстанавливать данные читая их с остальных вдисков группы.
+    Все данные хранимые VDisk'ом будут необратимо удалены, после чего VDisk начнет восстанавливать данные читая их с остальных VDisk'ов группы.
 
     ```bash
-    kikimr admin blobstorage group reconfigure wipe --domain <Номер домена> --node <ID узла> --pdisk <ID ПДиска> --vslot <Номер слота>
+    kikimr admin blobstorage group reconfigure wipe --domain <Номер домена> --node <ID узла> --pdisk <PDiskID> --vslot <Номер слота>
     ```
 
     Посмотреть нужную информацию для команды можно во вьювере (ссылка).
@@ -34,28 +34,28 @@
 
 1. Проверить состояние групп в кластере. Не должно быть проблемных групп которые находятся на том же узле, что и проблемное устройство.
 
-1. Зайти по ssh на узел где находится этот диск
+2. Зайти по ssh на узел где находится этот устройство
 
-1. Проверить, можно ли перезапустить процесс (ссылка на файл maintanence)
+3. Проверить, можно ли перезапустить процесс (ссылка на файл maintanence)
 
-1. Остановить процесс
+4. Остановить процесс
 
     ```bash
     sudo systemctl stop kikimr
     ```
 
-1. Форматировать диск
+5. Форматировать устройство
 
     ```bash
     sudo kikimr admin blobstorage disk obliterate <путь до партлейбла устройства>
     ```
 
-1. Запустить процесс
+6. Запустить процесс
 
     ```bash
     sudo systemctl start kikimr
     ```
 
-## Перевоз отдельных дисков с заполненных устройствах
+## Перевоз отдельных VDisk'ов с заполненных устройствах
 
-Если дефрагментация не помогает освободить место на устройстве, то можно [перевозить](moving_vdisks.md#moving_disk) отдельные виртуальные диски.
+Если дефрагментация не помогает освободить место на устройстве, то можно [перевозить](moving_vdisks.md#moving_disk) отдельные VDisk'и.
diff --git a/ydb/docs/ru/core/maintenance/manual/failure_model.md b/ydb/docs/ru/core/maintenance/manual/failure_model.md
index f543d1b24f..be79347530 100644
--- a/ydb/docs/ru/core/maintenance/manual/failure_model.md
+++ b/ydb/docs/ru/core/maintenance/manual/failure_model.md
@@ -2,21 +2,21 @@
 
 **Ссылка на статью в концептах о модели отказа скоро будет**
 
-## Отказал один диск в группе хранения {#storage_group_lost_one_disk}
+## Отказал один VDisk в группе хранения {#storage_group_lost_one_disk}
 
-При включенном SelfHeal данная ситуация счиается штатной. SelfHeal перевезет виртуальный диск за указанное в настройках время, после чего начнется процесс репликации данных на новом физическом диске.
+При включенном SelfHeal данная ситуация счиается штатной. SelfHeal перевезет VDisk за указанное в настройках время, после чего начнется процесс репликации данных на другом PDisk'е.
 
-Если же SelfHeal отключен, то перевоз диска потребуется провести вручную. Для это перед перевозом требуется убедиться в отказе **только одного** диска в группе хранения.
+Если же SelfHeal отключен, то перевоз VDisk'а потребуется провести вручную. Для это перед перевозом требуется убедиться в отказе **только одного** VDisk'а в группе хранения.
 После чего воспользоваться [инструкцией](moving_vdisks.md#removal_from_a_broken_device).
 
-## Отказало более одного диска в одной группе хранения без превышения модели {#storage_group_lost_more_than_one_disk}
+## Отказало более одного VDisk'а в одной группе хранения без превышения модели отказа {#storage_group_lost_more_than_one_disk}
 
 При таком отказе потери данных не происходит, система сохраняет работоспособность, успешно выполняются запросы на чтение и запись. Возможно падение производительности вызванное переносом нагрузки обрабатываемой отказавшими дисками на оставшиеся в строю.
 
-При отказе более одного диска в группе SelfHeal перестает перевозить диски. В случае если количество отказавших дисков находится на грани модели отказа, то рекомендуеся восстановить работоспособность хотя бы одного из дисков, прежде чем начинать [перевоз](moving_vdisks.md#removal_from_a_broken_device) виртуальных дисков на новые физические диски. Так же возможно потребуется более осторожно [перевозить диски по одноми](moving_vdisks.md#moving_vdisk).
+При отказе более одного VDisk'а в группе SelfHeal перестает перевозить VDisk'и. В случае если количество отказавших VDisk'ов находится на грани модели отказа, то рекомендуеся восстановить работоспособность хотя бы одного из VDisk'ов, прежде чем начинать [перевоз VDisk'ов](moving_vdisks.md#removal_from_a_broken_device). Так же возможно потребуется более осторожно [перевозить VDisk'и по одному](moving_vdisks.md#moving_vdisk).
 
-При одновременной недоступности 2 дисков по возможности рекомендуется восстановить работоспособность хотя бы одного из них, либо заменить один диск для начала процесса репликации. Это сохранит пространство для маневра в случае отказа третьего диска до завершения репликации.
+При одновременной недоступности 2 VDisk'ов по возможности рекомендуется восстановить работоспособность хотя бы одного из них, либо заменить один VDisk для начала процесса репликации. Это сохранит пространство для маневра в случае отказа третьего VDisk'а до завершения репликации.
 
-## Отказало более 2 дисков входящих в группу хранения block-4-2{#exceeded_the_failure_modele}
+## Количество отказавших VDisk'ов превысело модель отказа {#exceeded_the_failure_modele}
 
-Доступность и работоспособность системы может быть нарушена. Необходимо восстановить работоспособность хотя бы одного из дисков без потери хранившихся на нем данных.
+Доступность и работоспособность системы может быть нарушена. Необходимо восстановить работоспособность хотя бы одного из VDisk'ов без потери хранившихся на нем данных.
diff --git a/ydb/docs/ru/core/maintenance/manual/index.md b/ydb/docs/ru/core/maintenance/manual/index.md
index a136001861..f0124b0b86 100644
--- a/ydb/docs/ru/core/maintenance/manual/index.md
+++ b/ydb/docs/ru/core/maintenance/manual/index.md
@@ -16,7 +16,7 @@
 
 ## Изменение конфигурации кластера
 
-Кластер YDB позволяет проводить [расширение](cluster_expansion.md) и [декомиссию](cluster_decomision.md) устройств и узлов.
+Кластер YDB позволяет проводить [расширение](cluster_expansion.md) устройств и узлов.
 
 [Конфигурировать](change_actorsystem_configs.md) акторсистему на нодах.
 
diff --git a/ydb/docs/ru/core/maintenance/manual/moving_vdisks.md b/ydb/docs/ru/core/maintenance/manual/moving_vdisks.md
index 83166758c2..ca2daac7e5 100644
--- a/ydb/docs/ru/core/maintenance/manual/moving_vdisks.md
+++ b/ydb/docs/ru/core/maintenance/manual/moving_vdisks.md
@@ -1,8 +1,8 @@
-# Перевоз виртуальных дисков
+# Перевоз VDisk'ов
 
-## Увезти один вдиск с блочного устройтства {#moving_vdisk}
+## Увезти один VDisk'ов с блочного устройтства {#moving_vdisk}
 
-Для того чтобы перевезти диск с блочного устройства, надо зайти на ноду по ssh и выполнить следующую команду.
+Для того чтобы перевезти VDisk'и с блочного устройства, надо зайти на ноду по ssh и выполнить следующую команду.
 
 ```bash
 kikimr admin bs config invoke --proto 'Command { ReassignGroupDisk { GroupId: <ID группы хранения> GroupGeneration: <Поколение группы хранения> FailRealmIdx: <FailRealm> FailDomainIdx: <FailDomain> VDiskIdx: <Номер слота> } }'
@@ -10,32 +10,32 @@ kikimr admin bs config invoke --proto 'Command { ReassignGroupDisk { GroupId: <I
 
 Нужную информацию для выполнения команды можно посмотреть во вьювере (ссылка).
 
-## Перевезти вдиски со сломанного/отсутствующего устройства {#removal_from_a_broken_device}
+## Перевезти VDisk'и со сломанного/отсутствующего устройства {#removal_from_a_broken_device}
 
-В случае если SelfHeal выключен или не перевозит вдиски, данную операцию придется выполнить вручную.
+В случае если SelfHeal выключен или не перевозит VDisk'и, данную операцию придется выполнить вручную.
 
-1. Убедиться в мониторинге, что диск действительно в нерабочем состоянии.  
+1. Убедиться в мониторинге, что VDisk действительно в нерабочем состоянии.
 
-    Записать fqdn узла, ic-port, путь до диска, pdiskId
+    Записать fqdn узла, ic-port, путь до VDisk'а, pdiskId
 
 2. Зайти на любой узел кластера
 
-3. Выполнить перевоз диска
+3. Выполнить перевоз VDisk'а
 
     ```bash
-    kikimr admin bs config invoke --proto 'Command { UpdateDriveStatus { HostKey: { Fqdn: "<Xост>" IcPort: <IC Порт>} Path: "<Путь до партлейбла устройства>" PDiskId: <ID ПДиска> Status: BROKEN } }'
+    kikimr admin bs config invoke --proto 'Command { UpdateDriveStatus { HostKey: { Fqdn: "<Xост>" IcPort: <ic-port>} Path: "<Путь до партлейбла устройства>" PDiskId: <PDiskID> Status: BROKEN } }'
     ```
 
-## Вернуть диск после развоза  {#return_a_device_to_work}
+## Вернуть PDisk после развоза  {#return_a_device_to_work}
 
-1. Убедиться в мониторинге, что диск в рабочем состоянии  
+1. Убедиться в мониторинге, что PDisk в рабочем состоянии
 
-    Записать fqdn узла, ic-port, путь до диска, pdiskId
+    Записать fqdn узла, ic-port, путь до устройства, pdiskId
 
 2. Зайти на любой узел кластера
 
-3. Вернуть диск
+3. Вернуть PDisk
 
     ```bash
     kikimr admin bs config invoke --proto 'Command { UpdateDriveStatus { HostKey: { Fqdn: "<Xост>" IcPort: <IC Порт>} Path: "<Путь до партлейбла устройства>" PDiskId: <ID ПДиска> Status: ACTIVE } }'
-    ```
\ No newline at end of file
+    ```
diff --git a/ydb/docs/ru/core/maintenance/manual/node_restarting.md b/ydb/docs/ru/core/maintenance/manual/node_restarting.md
index 77295d71ed..75c97a699d 100644
--- a/ydb/docs/ru/core/maintenance/manual/node_restarting.md
+++ b/ydb/docs/ru/core/maintenance/manual/node_restarting.md
@@ -29,7 +29,7 @@
 ## Замена оборудования {#replace_hardware}
 
 Перед заменой нужно убедиться, что процесс ydb можно [остановить](#restart_process).  
-При длительном отсутствии стоит перед этим перевезти все вдиски с данного узла и дождаться окончания репликации.  
+При длительном отсутствии стоит перед этим перевезти все VDisk'и с данного узла и дождаться окончания репликации.  
 После окончания репликации узел можно безопасно выключать.
 
 Для отключения динамической узлы так же може потребоваться провести дрейн таблеток, дабы избежать эффекта на работающие запросы.
diff --git a/ydb/docs/ru/core/maintenance/manual/selfheal.md b/ydb/docs/ru/core/maintenance/manual/selfheal.md
index e67780d72f..8ac692ba5d 100644
--- a/ydb/docs/ru/core/maintenance/manual/selfheal.md
+++ b/ydb/docs/ru/core/maintenance/manual/selfheal.md
@@ -76,8 +76,8 @@ viewer -> Cluster Management System -> CmsConfigItems
 * **InitialSysLogRead** - PDisk читает системный лог. Переход в FAULTY.
 * **InitialSysLogReadError** - PDisk получил ошибку при чтении системного лога. Переход в FAULTY.
 * **InitialSysLogParseError** - PDisk получил ошибку при парсинге или проверке консистентности системного лога. Переход в FAULTY.
-* **InitialCommonnLogRead** - PDisk читает общий лог вдисков. Переход в FAULTY.
-* **InitialCommonnLogReadError** - PDisk получил ошибку при чтении общего лога вдисков. Переход в FAULTY.
+* **InitialCommonnLogRead** - PDisk читает общий лог VDisk'ов. Переход в FAULTY.
+* **InitialCommonnLogReadError** - PDisk получил ошибку при чтении общего лога VDisk'ов. Переход в FAULTY.
 * **InitialCommonnLogParseError** - PDisk получил ошибку при парсинге или проверке консистентности общего лога. Переход в FAULTY.
 * **CommonLoggerInitError** - PDisk получил ошибку при инициализации внутренних структур предназначенных для записи в общий лог. Переход в FAULTY.
 * **Normal** - PDisk завершил иницализацию и работает нормально. Переход в ACTIVE произойдет через это количество Циклов (т.е. по умолчанию если Normal держится 5 минут, переводим диск в ACTIVE)
@@ -89,17 +89,17 @@ viewer -> Cluster Management System -> CmsConfigItems
 
 ## Включение/выключение дисков-доноров
 
-При выключенных дисках донорах, при перевозе вдиска, его данные теряются, и их приходится восстанавливать согласно выбранному erasure.
+При выключенных дисках донорах, при перевозе VDisk'а, его данные теряются, и их приходится восстанавливать согласно выбранному erasure.
 
 Операция восстановления дороже, чем обычный перевоз данных. Так же происходит потеря данных, что може повлечь за собой потерю данных при выходе за рамки модели отказа.
 
 Для предотвращения выше перечисленных проблем, существуют диски доноры.
 
-При перевозе дисков с включенными дисками донорами, старый вдиск остается жить до тех пор пока новый не перенесет все данные из него к себе.
+При перевозе дисков с включенными дисками донорами, старый VDisk остается жить до тех пор пока новый не перенесет все данные из него к себе.
 
-Диск донор, это старый вдиск после перевоза, который продолжает хранить свои данные и отвечает только на запросы чтения от нового вдиска.
+Диск донор, это старый VDisk'ов после перевоза, который продолжает хранить свои данные и отвечает только на запросы чтения от нового VDisk'а.
 
-При получении запроса на чтения на данные, которые новый вдиск еще не успел перенести, он перенаправляет запрос к диску донору.
+При получении запроса на чтения на данные, которые новый VDisk еще не успел перенести, он перенаправляет запрос к диску донору.
 
 Для включения дисков-доноров, требуется выполнить следующую команду:
 
diff --git a/ydb/docs/ru/core/maintenance/toc_i.yaml b/ydb/docs/ru/core/maintenance/toc_i.yaml
index 8b3653e679..0d9f0ff4a5 100644
--- a/ydb/docs/ru/core/maintenance/toc_i.yaml
+++ b/ydb/docs/ru/core/maintenance/toc_i.yaml
@@ -33,8 +33,6 @@ items:
       href: manual/disk_end_space.md
     - name: Расширение кластера
       href: manual/cluster_expansion.md
-    - name: Декоммиссия узлов и дисков
-      href: manual/cluster_decomision.md
     - name: Добавление групп хранения
       href: manual/adding_storage_groups.md
     - name: Безопасные рестарт и выключение узлов
@@ -43,7 +41,7 @@ items:
       href: manual/selfheal.md
     - name: Включение/выключение Scrubbing
       href: manual/scrubbing.md
-    - name: Перевоз виртуальных дисков
+    - name: Перевоз VDisk'ов
       href: manual/moving_vdisks.md
     - name: Изменение конфигураций через CMS
       href: manual/cms.md