diff --git a/docs/cluster.png b/docs/cluster.png
deleted file mode 100644
index fbf86ab61ffa0757aeb865d1090fa6d7284e2d38..0000000000000000000000000000000000000000
Binary files a/docs/cluster.png and /dev/null differ
diff --git a/docs/cluster.svg b/docs/cluster.svg
new file mode 100644
index 0000000000000000000000000000000000000000..68aa307760ecebc2ad5912dda63eec60522df84f
Binary files /dev/null and b/docs/cluster.svg differ
diff --git a/docs/description.md b/docs/description.md
index 11d67865eceea75252ee4b22783c8a621226ef0c..bd91bbe7a56cbef34a58b509f1a2e3942ac991ab 100644
--- a/docs/description.md
+++ b/docs/description.md
@@ -4,7 +4,7 @@
 Picodata предоставляет систему хранения данных и платформу для работы персистентных приложений на языке Rust и средства управления СУБД на языке SQL.
 
 ## Назначение
-Основным предназначением продукта Picodata является горизонтально масштабируемое хранение структурированных и неструктурированных данных, управление ими, предоставление среды вычислений внутри кластера.
+Основным предназначением продукта Picodata является горизонтально масштабируемое хранение структурированных и неструктурированных данных, управление ими, предоставление среды вычислений внутри кластера, состоящего из реплицированных отдельных узлов. Такие узлы называют экземплярами Picodata или *инстансами*.
 
 ## Задачи
 Задачи, решаемые ПО Picodata, включают в себя:
@@ -12,7 +12,7 @@ Picodata предоставляет систему хранения данных
 * Реализацию общего линеаризованного хранилища конфигурации, схемы данных и топологии кластера, встроенного в распределенную систему управления базами данных.
 * Предоставление графического интерфейса и интерфейса командной строки по управлению топологией кластера.
 * Реализацию runtime-библиотек по работе с сетью, файловому вводу-выводу, созданию зеленых потоков (green threads) и управлению ими, работе со встроенной СУБД средствами языка Rust.
-* Поддержку языка SQL для работы как с данными одного узла кластера, так и с данными всего кластера.
+* Поддержку языка SQL для работы как с данными отдельного инстанса, так и с данными всего кластера.
 * Управление кластером.
 * Поддержку жизненного цикла приложения в кластере, включая версионирование, управление зависимостями, упаковку дистрибутива, развертывание и обновление запущенных приложений.
 
@@ -27,34 +27,48 @@ Picodata предоставляет систему хранения данных
 * и многое другое!
 
 ## Преимущества
-Picodata позволяет развёртывать и управлять кластерами с СУБД Tarantool, используя следующие возможности:
+Кластер с СУБД Picodata имеет следующие преимущества:
+
+* автоматическое горизонтальное масштабирование кластера;
+* более простая настройка для запуска шардированного кластера. Требуется меньше файлов конфигурации;
+* совместимость с любыми инструментами развёртывания инстансов (Ansible, Chef, Puppet);
+* обеспечение высокой доступности данных без необходимости в  кластере Etcd и дополнительных настройках;
+* автоматическое определение активного инстанса в репликасетах любого размера;
+* единая схема данных во всех репликасетах кластера;
+* возможность обновлять схему данных и менять топологию работающего кластера, например добавлять новые инстансы. Picodata автоматически управляет версиями схемы; 
+* встроенные инструменты для создания и запуска приложений.
 
-* горизонтальное масштабирование кластера с использованием библиотеки логического шардирования VShard и собственных высокоуровневых инструментов, облегчающих работу администраторов и разработчиков.
-* гибкое управление вычислительной нагрузкой за счёт реплицирования узлов кластера и автоматизированной балансировки.
-* гибкое удаление устаревших данных.
-* гибкое обновление схемы данных и изменение топологии кластера,в например добавление новых узлов к уже работающему кластеру.
-* обеспечение высокой доступности и персистентности данных сразу, без использования дополнительного инструментария.
 
 ## Архитектура
-Архитектура кластера под управлением Picodata предполагает систему узлов, входящих в состав кластера. Каждый узел может выполнять различные роли, например роль хранения данных, роль сервера приложения, или служебную роль координатора кластера.
-Все узлы работают с единой схемой данных и кодом приложения. Каждый процесс базы данных выполняется на одном процессорном ядре и хранит все свои данные в оперативной памяти. 
-Любой отдельный узел является часть набора реплик, который также называют *репликасетом*. Репликасет может состоять из одного узла или нескольких дубликатов одного и того же набора данных. Внутри репликасета всегда есть *лидер* (основной узел) и — если реплик больше 1 — то некоторое число вспомогательных узлов, обеспечивающие отказоустойчивость системы в случае выхода из строя или недоступности лидера. Число реплик определяется *фактором репликации*, заданным для набора в глобальных настройках Picodata.
+### Составные части кластера
+Архитектура кластера Picodata предполагает систему отдельных *инстансов* — программных узлов, входящих в состав кластера. Каждый такой узел может выполнять различные роли, например роль хранения данных, роль сервера приложения, или служебную роль координатора кластера.
+Все инстансы работают с единой схемой данных и кодом приложения. Каждый процесс базы данных выполняется на одном процессорном ядре и хранит используемый набор данных в оперативной памяти. 
+Любой отдельный инстанс является частью набора реплик, который также называют *репликасетом*. Репликасет может состоять из одного или нескольких инстансов — дубликатов одного и того же набора данных. Внутри репликасета всегда есть *активный* инстанс и — если реплик больше 1 — то некоторое число дополнительных инстансов, обеспечивающих отказоустойчивость системы в случае выхода из строя или недоступности активного инстанса. Число реплик определяется *фактором репликации*, заданным в глобальных настройках Picodata.
+
+На рисунке ниже показана схема простого кластера из двух репликасетов, каждый из которых состоит из двух инстансов (активного и резервного):
 
-На рисунке ниже показана схема простого кластера из двух репликасетов, каждый из которых состоит из двух узлов (активного и в ожидании):
+![Схема кластера](cluster.svg)
 
-![Схема кластера](cluster.png)
+Репликасеты являются единицами горизонтального масштабирования кластера. Данные балансируются между ними автоматически.
 
-Репликасеты являются единицами физического масштабирования кластера. Данные балансируются между ними автоматически.
-Внутри каждого репликасета есть *bucket* — виртуализированная неделимая единица хранения, обеспечивающая локальность данных (например, хранение нескольких связанных с клиентом записей на одном физическом узле). Таким образом, при горизонтальном масштабировании кластера данные распределяются по устройствам хранения не напрямую, а внутри bucket'ов. Это позволяет увеличить скорость выполнения запросов к БД и одновременно с этим снизить нагрузку на сетевую инфраструктуру кластера. Bucket всегда хранится физически на одном узле и является промежуточным звеном между данными и устройством хранения. В каждом репликасете может быть много bucket'ов (или не быть не одного). Внутри bucket'а данные задублированы по всем узлам в рамках репликасета в соответствие с фактором репликации.
+### Хранение данных
+Внутри каждого репликасета есть *bucket* — виртуализированная неделимая единица хранения, обеспечивающая локальность данных (например, хранение нескольких связанных с клиентом записей на одном физическом узле сети). Сам по себе bucket не имеет ограничений по ёмкости и может содержать любой объём данных. Горизонтальное масштабирование позволяет распределить bucket'ы по разным шардам, оптимизировав производительность кластера путём добавления новых реплицированных инстансов. Чем больше репликасетов входит в состав кластера, тем меньше нагрузка на каждый из них. Bucket хранится физически на одном репликасете и является промежуточным звеном между данными и устройством хранения. В каждом репликасете может быть много bucket'ов (или не быть не одного). Внутри bucket'а данные задублированы по всем инстансам в рамках репликасета в соответствии с фактором репликации. Количество bucket'ов задаётся при первоначальной настройке кластера.
 
 На схеме ниже показан пример схемы хранения данных внутри репликасета:
 
-![Хранение данных](storage.png)
+![Хранение данных](storage.svg)
 
-Узлы внутри репликасета обеспечивают его отказоустойчивость. Однако, для повышения надёжности каждый узел внутри репликасета находится на разных физических серверах, а также, как правило, в разных, географически удалённых друг от друга датацентрах. Таким образом, репликасет становится *распределённым* и в случае недоступности или выходы из строя датацентра продолжает работать, делая активным другой узел. За распределение узлов между разными серверами отвечает библиотека Tarantool vShard, используемая в Picodata. 
+### Отказоустойчивость
+Наличие нескольких реплик внутри репликасета обеспечивают его отказоустойчивость. Дополнительно для повышения надёжности каждый инстанс кластера внутри репликасета находится на разных физических серверах, а в некоторых случаях — в удалённых друг от друга датацентрах. Таким образом, в случае недоступности датацентра в репликасете происходит переключение на резервную реплику (инстанс) без прерывания работы. 
 
 Пример географического распределения репликасета показан на схеме ниже:
 
-![Шардирование](sharding.png)
+![Отказоустойчивость](failover.svg)
+
+### Шардирование
+Шардирование — это распределение bucket'ов между различными репликасетами. В Picodata используется основанное на хэшах шардирование с хранением данных в виртуальных bucket'ах. Каждый репликасет является *шардом*, и чем больше репликасетов имеется в кластере, тем эффективнее данная функция может разделить массив данных на отдельные наборы данных меньшего размера. При добавлении новых инстансов в кластер и/или формировании новых репликасетов, Picodata автоматически равномерно распределит bucket'ы с учётом новой конфигурации.
+Пример автоматического шардирования при добавлении в кластер новых инстансов показан на схеме ниже:
+
+![Шардирование](sharding.svg)
 
-Таким образом, каждый узел является *репликасетом*, а каждый репликасет — *шардом*.
\ No newline at end of file
+Таким образом, каждый инстанс (экземпляр Picodata) является *частью репликасета*, а каждый репликасет — *шардом*, а шарды распределены между несколькими серверами.
\ No newline at end of file
diff --git a/docs/failover.svg b/docs/failover.svg
new file mode 100644
index 0000000000000000000000000000000000000000..fe7e3a9443c68921920916cd2eb61edb97c46481
Binary files /dev/null and b/docs/failover.svg differ
diff --git a/docs/sharding.png b/docs/sharding.png
deleted file mode 100644
index 8859c926fbb333a90309d36eb19af5d85f6c0778..0000000000000000000000000000000000000000
Binary files a/docs/sharding.png and /dev/null differ
diff --git a/docs/sharding.svg b/docs/sharding.svg
new file mode 100644
index 0000000000000000000000000000000000000000..c403d1e8e47484e33a0962c88bfc1b19f4f7ae30
Binary files /dev/null and b/docs/sharding.svg differ
diff --git a/docs/source_images/cluster.svg b/docs/source_images/cluster.svg
new file mode 100644
index 0000000000000000000000000000000000000000..48ede2600e9be237113f47b1f267cbdfaaf130ee
Binary files /dev/null and b/docs/source_images/cluster.svg differ
diff --git a/docs/source_images/cluster_ru.svg b/docs/source_images/cluster_ru.svg
new file mode 100644
index 0000000000000000000000000000000000000000..6cec4f8b026db9513ac21e2aa6bbad571fb99bb8
Binary files /dev/null and b/docs/source_images/cluster_ru.svg differ
diff --git a/docs/source_images/failover.svg b/docs/source_images/failover.svg
new file mode 100644
index 0000000000000000000000000000000000000000..aadee796166d52f58602f5366e7fe332b4bff99d
Binary files /dev/null and b/docs/source_images/failover.svg differ
diff --git a/docs/source_images/failover_ru.svg b/docs/source_images/failover_ru.svg
new file mode 100644
index 0000000000000000000000000000000000000000..348369dc6288b1e9fee9a7c4d21c14f422408252
Binary files /dev/null and b/docs/source_images/failover_ru.svg differ
diff --git a/docs/source_images/sharding.svg b/docs/source_images/sharding.svg
new file mode 100644
index 0000000000000000000000000000000000000000..cf074972006c61cbbaa078072ee396c2ed32b113
Binary files /dev/null and b/docs/source_images/sharding.svg differ
diff --git a/docs/source_images/sharding_ru.svg b/docs/source_images/sharding_ru.svg
new file mode 100644
index 0000000000000000000000000000000000000000..c2acc93d3cbc8d5f31314a00838477283842f859
Binary files /dev/null and b/docs/source_images/sharding_ru.svg differ
diff --git a/docs/source_images/storage.svg b/docs/source_images/storage.svg
new file mode 100644
index 0000000000000000000000000000000000000000..ddd3a2d8cec1476c30d4ceecc0080e1b536ec728
Binary files /dev/null and b/docs/source_images/storage.svg differ
diff --git a/docs/source_images/storage_ru.svg b/docs/source_images/storage_ru.svg
new file mode 100644
index 0000000000000000000000000000000000000000..d0dc6721ce4f065237f4ed796a742666eb78d67e
Binary files /dev/null and b/docs/source_images/storage_ru.svg differ
diff --git a/docs/startup.md b/docs/startup.md
new file mode 100644
index 0000000000000000000000000000000000000000..2d628a6ed226226c6b95265a13c6aaef16c9a3e5
--- /dev/null
+++ b/docs/startup.md
@@ -0,0 +1,17 @@
+## Настройка и запуск кластера
+Picodata позволяет запустить отдельные экземпляры Tarantool (инстансы) и тут же собрать их в один кластер. Каждый инстанс при запуске содержит ряд обязательных параметров, включая:
+
+* идентификатор кластера (должен совпадать у всех инстансов);
+* уникальный идентификатор самого инстанса;
+* фактор репликации (число инстансов в репликасете);
+* сетевой адрес и порт текущего инстанса (*peer*) и желательно какого-либо другого инстанса;
+* домен отказа (принадлежность инстанса физическому серверу).
+
+Для того чтобы все инстансы сформировали один кластер, нужно для каждого из них указать набор peer'ов хотя бы из двух позиций: текущего инстанса и какого-либо другого (или несколько других). Picodata сможет собрать кластер при выполнении следующего условия: **у любой пары инстансов должен быть хотя бы один общий *peer***. 
+
+Использование параметра *домен отказа* (failure domain) необходимо для того, чтобы в репликасет попали инстансы, запущенные на разных серверах или датацентрах. Это обеспечит необходимую отказоустойчивость.
+Для сборки и поддержания работы кластера Picodata использует алгоритм Raft, который хранит глобальную конфигурацию всех инстансов в специальном журнале Raft Log. Из него эти данные автоматически попадают в локальные конфигурации отдельных экземпляров Tarantool. В частности, эти данные включают в себя информацию о репликасетах и адреса находящихся в них инстансах, что необходимо для шардирования (распределения bucket'ов по репликасетам).
+
+*Что именно хранится в рафт-логе?*
+
+Picodata позволяет работать с глобальной конфигурацией кластера и администрировать его без трудоёмкой и ненадёжной перенастройки отдельных инстансов. 
\ No newline at end of file
diff --git a/docs/storage.png b/docs/storage.png
deleted file mode 100644
index aa2e836b8a46a41afc69c44cce78c29e259a795f..0000000000000000000000000000000000000000
Binary files a/docs/storage.png and /dev/null differ
diff --git a/docs/storage.svg b/docs/storage.svg
new file mode 100644
index 0000000000000000000000000000000000000000..34555a73cbaa5a7aed0fbe35496460043db98688
Binary files /dev/null and b/docs/storage.svg differ