mirror of
https://github.com/ada-dmitry/ada-dmitry.github.io.git
synced 2026-09-24 01:10:35 +00:00
Add notes for Home Server setup and IT School curriculum
- Created a new note on setting up a Home Server with Proxmox, detailing hardware choices, NAT, and remote access solutions. - Added a comprehensive overview of the IT School curriculum, covering topics such as IT infrastructure, automation, virtualization, and more. - Included detailed notes on various aspects of IT infrastructure, including hardware components, network storage, and cloud models. - Documented the importance of automation in infrastructure management and introduced key tools and methodologies like DevOps and Infrastructure as Code. - Explained virtualization concepts, including hypervisors, containers, and software-defined networking, along with practical scenarios and benefits.
This commit is contained in:
ada
@@ -0,0 +1,508 @@
|
||||
---
|
||||
title: Введение в виртуализацию
|
||||
---
|
||||
|
||||
> Лектор: Артур Марцинкевич - Системный инженер Департамента инфраструктурных решений и сервисов
|
||||
|
||||
## 🧱 Архитектура систем
|
||||
|
||||
---
|
||||
|
||||
### 🖥️ Bare-metal
|
||||
|
||||
- Приложение A + ОС сервера работают *напрямую* на физическом сервере.
|
||||
- Попытка запустить дополнительное приложение может привести к сбоям из-за отсутствия изоляции.
|
||||
|
||||
> ❗ Нет изоляции между компонентами → высокая зависимость приложений друг от друга.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 💻 Виртуализация
|
||||
|
||||
- Используется облегчённая ОС-гипервизор *первого типа*.
|
||||
- Каждое приложение запускается в *отдельной виртуальной машине* (ВМ).
|
||||
- ВМ полностью изолированы: имеют свои ядра, ОС и ресурсы.
|
||||
|
||||
**Преимущества:**
|
||||
- Изоляция не только вычислительных ресурсов, но и сетевых, дисковых и др.
|
||||
- Возможность развёртывания нескольких независимых окружений.
|
||||
|
||||
**Примеры гипервизоров:**
|
||||
1. QEMU-KVM
|
||||
2. Xen
|
||||
3. ESX / ESXi
|
||||
4. Hyper-V
|
||||
5. ...
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 📦 Контейнеризация
|
||||
|
||||
> ❗ Проблема виртуализации — значительные ресурсы уходят на эмуляцию "железа" и отдельных ОС.
|
||||
|
||||
**Контейнеризация** — решение этой проблемы:
|
||||
|
||||
- Контейнеры запускаются на общем ядре ОС, используют её ресурсы.
|
||||
- Более лёгкие, чем ВМ, но всё ещё изолированы.
|
||||
- Контейнер = изолированное окружение процесса с зависимостями.
|
||||
|
||||
**Примеры:**
|
||||
1. Docker
|
||||
2. Podman
|
||||
3. LXC
|
||||
4. OpenVZ
|
||||
5. FreeBSD Jails
|
||||
|
||||
|
||||
|
||||
**Особенности:**
|
||||
- Меньшая изоляция, чем у ВМ, но больше, чем у обычных процессов.
|
||||
- Одно общее ядро (например, Linux).
|
||||
- Используется интерфейс контейнеризации: **CRI (Container Runtime Interface)**.
|
||||
|
||||
---
|
||||
|
||||
### ⚙️ Гипервизоры: Типы
|
||||
|
||||
1. **Гипервизор первого типа (bare-metal)** — запускается напрямую на "железе", минуя ОС.
|
||||
2. **Гипервизор второго типа (hosted)** — устанавливается как приложение на существующую ОС.
|
||||
|
||||
| Тип | Преимущество | Недостаток |
|
||||
| ------------------- | ------------------------------------ | -------------------------- |
|
||||
| Первый (bare-metal) | Высокая производительность | Сложность настройки |
|
||||
| Второй (hosted) | Удобство в тестировании и разработке | Меньшая производительность |
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🧪 QEMU-KVM
|
||||
|
||||
- **KVM (Kernel-based Virtual Machine)** — модуль ядра Linux, превращающий его в гипервизор. Использует технологии аппаратной виртуализации (Intel VT-x, AMD-V).
|
||||
- **QEMU (Quick Emulator)** — эмулятор аппаратного обеспечения, который может запускать виртуальные машины с разными ОС и архитектурами. Может использоваться как с KVM (для ускорения), так и отдельно.
|
||||
|
||||
> 💡 Вместе QEMU + KVM обеспечивают производительную и гибкую виртуализацию на Linux.
|
||||
|
||||
|
||||
|
||||
### 🧩 Libvirt
|
||||
|
||||
**Libvirt** — это *прослойка* между гипервизором и аппаратным обеспечением, предназначенная для унификации управления виртуальными машинами.
|
||||
|
||||
> 🧠 **Libvirt** — набор инструментов и библиотек, позволяющий управлять виртуализацией: ВМ, сетями, хранилищами и др., через единый интерфейс.
|
||||
|
||||
**Преимущества:**
|
||||
- Унифицированный API для разных гипервизоров (KVM, QEMU, Xen, LXC и др.)
|
||||
- Управление ВМ, снапшотами, сетями, пулом хранилищ и др.
|
||||
- Поддержка как командной строки (`virsh`), так и графических интерфейсов (`virt-manager`)
|
||||
- Используется в автоматизации и DevOps-инструментах
|
||||
|
||||
> 💡 Позволяет абстрагироваться от специфики конкретного гипервизора.
|
||||
|
||||
|
||||
|
||||
|
||||
### 🧰 Платформы виртуализации
|
||||
|
||||
#### Компоненты платформы:
|
||||
|
||||
- **🖥️ Серверное оборудование**
|
||||
> Физические серверы, на которых размещаются виртуальные машины (ВМ).
|
||||
|
||||
- **🌐 Сетевое оборудование**
|
||||
> Физические и виртуальные коммутаторы, маршрутизаторы и другие компоненты, обеспечивающие связь между ВМ и внешним миром.
|
||||
|
||||
- **💾 Хранилища**
|
||||
> Системы хранения данных (SAN, NAS), содержащие образы ВМ, снапшоты, ISO-файлы и пр.
|
||||
|
||||
- **🔗 Интеграция с внешними системами**
|
||||
> Взаимодействие с AD, LDAP, CI/CD, системами резервного копирования и др.
|
||||
|
||||
- **👤 Управление пользователями**
|
||||
> Создание, аутентификация и авторизация пользователей с разграничением прав доступа.
|
||||
|
||||
- **🔁 Высокая доступность (HA)**
|
||||
> Механизмы автоматического восстановления при сбоях (кластеризация, репликация и т.д.).
|
||||
|
||||
> 💥 **Split Brain** — ситуация, когда узлы кластера теряют связь между собой, считают друг друга "павшими" и продолжают работать независимо, что может привести к конфликтам данных.
|
||||
|
||||
- **🔐 Ролевая модель доступа**
|
||||
> Разделение полномочий: администраторы, операторы, разработчики, пользователи и т.д.
|
||||
|
||||
- **⚖️ Балансировка нагрузки**
|
||||
> Автоматическое распределение ресурсов и ВМ между хостами для оптимальной производительности.
|
||||
|
||||
- **📊 Мониторинг и аудит**
|
||||
> Наблюдение за состоянием инфраструктуры, алерты, журналы событий, аудит действий пользователей.
|
||||
|
||||
- **📈 Квоты и QoS (Quality of Service)**
|
||||
> Ограничения на использование ресурсов (CPU, RAM, диск), контроль за качеством обслуживания.
|
||||
|
||||
---
|
||||
|
||||
### 🔄 Сценарии использования виртуализации:
|
||||
|
||||
1. 🧱 **Базовая виртуализация** — развёртывание нескольких ВМ на одном физическом сервере.
|
||||
2. 🧮 **Консолидация ресурсов** — сокращение числа физических серверов, повышение эффективности.
|
||||
3. 🛡️ **Катастрофоустойчивость** — резервные и растянутые ЦОДы для непрерывности бизнеса.
|
||||
4. 🧑💻 **Виртуализация рабочих мест** — создание удалённых рабочих столов и VDI-инфраструктур.
|
||||
5. ☁️ **Облачные инфраструктуры** — частные, публичные и гибридные облака.
|
||||
6. 🧪 **Разработка и тестирование** — быстрое развёртывание тестовых сред и CI/CD пайплайнов.
|
||||
|
||||
|
||||
### 🗄️ Виртуализация сетей хранения данных (SDS — Software Defined Storage)
|
||||
|
||||
**SDS (программно-определяемое хранилище)** — подход к управлению хранилищами, при котором программное обеспечение отделено от аппаратного обеспечения. Это позволяет гибко масштабировать и управлять ресурсами хранения.
|
||||
|
||||
---
|
||||
|
||||
#### 📌 Подходы к реализации SDS:
|
||||
|
||||
1. **Традиционная СХД**
|
||||
> Покупка нескольких физических систем хранения данных (СХД) и объединение их в одну логическую СХД с помощью внешнего контроллера.
|
||||
|
||||
2. **Программно-определяемая СХД**
|
||||
> Покупка обычных серверов, установка SDS-клиента на каждый и объединение их в единую систему хранения через SDS-сервер (или управляющий узел).
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
**Преимущества SDS:**
|
||||
- Масштабируемость "по потребности"
|
||||
- Независимость от конкретного производителя железа
|
||||
- Более простое управление и автоматизация
|
||||
- Повышенная отказоустойчивость при грамотной настройке
|
||||
|
||||
> 💡 SDS — ключевой компонент современных гибридных и частных облаков.
|
||||
|
||||
|
||||
|
||||
### 📦 Сценарии использования SDS (программно-определяемых хранилищ)
|
||||
|
||||
1. **Абстракция физического уровня хранения**
|
||||
> Отделение логической структуры данных от физического носителя. Упрощает управление и масштабирование.
|
||||
|
||||
2. **Гиперконвергентная инфраструктура (HCI)**
|
||||
> Объединение вычислений, хранения и сетей в единую программно управляемую платформу.
|
||||
|
||||
3. **Использование стандартного и недорогого оборудования**
|
||||
> Возможность развертывания хранилища на обычных x86-серверах без дорогих специализированных СХД.
|
||||
|
||||
4. **Горизонтально масштабируемая архитектура**
|
||||
> Добавление новых узлов без полной перестройки системы. Масштабирование "вширь", а не "вглубь".
|
||||
|
||||
## 🌐 Виртуализация сетей
|
||||
|
||||
**Программно-определяемые сети (SDN, Software-defined Networking)** — подход к построению сетевой инфраструктуры, в котором управление сетью выносится в *отдельный* программный уровень.
|
||||
|
||||
---
|
||||
|
||||
### 📌 Суть SDN
|
||||
|
||||
SDN отделяет **плоскость управления** (Control Plane) от **плоскости передачи данных** (Data Plane):
|
||||
|
||||
- **Control Plane** — логика управления (маршрутизация, правила фильтрации, балансировка).
|
||||
- **Data Plane** — физическая передача пакетов между устройствами.
|
||||
|
||||
> В традиционной сети эти два слоя "вшиты" в каждый коммутатор или маршрутизатор.
|
||||
> В SDN управление централизовано: всем управляет **SDN-контроллер**.
|
||||
|
||||
---
|
||||
|
||||
### 🧱 Архитектура
|
||||
|
||||
#### Традиционная архитектура:
|
||||
|
||||
- Управление и передача данных объединены в каждом сетевом устройстве.
|
||||
- Сложно централизованно управлять, вносить изменения и масштабировать.
|
||||
|
||||
#### SDN-архитектура:
|
||||
|
||||
- **Централизованный контроллер** управляет всеми сетевыми устройствами.
|
||||
- Устройства работают как "исполнители", передавая трафик по полученным правилам.
|
||||
|
||||
### ✅ Преимущества SDN:
|
||||
|
||||
- Централизованное управление всей сетью
|
||||
- Быстрая настройка и обновление правил маршрутизации
|
||||
- Высокая гибкость и масштабируемость
|
||||
- Простота автоматизации и интеграции с DevOps/CI/CD
|
||||
- Улучшенная безопасность через сегментацию и контроль доступа
|
||||
|
||||
---
|
||||
|
||||
### 📦 Примеры решений:
|
||||
|
||||
- **Контроллеры**: OpenDaylight, ONOS, Ryu
|
||||
- **Протоколы**: OpenFlow, NETCONF, REST API
|
||||
- **SDN-платформы**: Cisco ACI, VMware NSX, Juniper Contrail
|
||||
|
||||
---
|
||||
|
||||
> 💡 SDN — основа современной сетевой виртуализации и облачной инфраструктуры.
|
||||
|
||||
|
||||
## 🌐 Виртуальная сеть
|
||||
|
||||
Виртуальная сеть позволяет виртуальным машинам (ВМ) обмениваться данными внутри хоста и выходить во внешнюю сеть, используя программные сетевые компоненты.
|
||||
|
||||
---
|
||||
|
||||
### 🧩 Компоненты:
|
||||
|
||||
- **vNIC (virtual Network Interface Card)** — виртуальный сетевой адаптер, создаваемый для каждой ВМ.
|
||||
- **vSwitch (virtual Switch)** — виртуальный коммутатор, к которому подключаются все vNIC.
|
||||
- **NIC** — физический сетевой адаптер хоста.
|
||||
- **Switch** — физический сетевой коммутатор, соединяющий сервер с внешней сетью.
|
||||
|
||||
---
|
||||
|
||||
### 🔄 Как работает:
|
||||
|
||||
1. Каждая ВМ получает собственный **vNIC**.
|
||||
2. Все vNIC подключаются к общему **vSwitch**.
|
||||
3. **vSwitch** передаёт трафик на **NIC** — физический сетевой адаптер сервера.
|
||||
4. NIC соединяется с физическим **Switch** — точкой входа/выхода в реальную сеть.
|
||||
|
||||
## 🚀 Сценарии использования SDN (Software-defined Networking)
|
||||
|
||||
1. **Абстракция программных сетей от физической сетевой инфраструктуры**
|
||||
> Логика управления сетью выносится за пределы оборудования, что упрощает масштабирование и миграцию.
|
||||
|
||||
2. **Независимость от производителя сетевого оборудования**
|
||||
> Использование открытых стандартов и интерфейсов позволяет не зависеть от конкретных вендоров.
|
||||
|
||||
3. **Гибкость конфигурации сетевой инфраструктуры**
|
||||
> Быстрое изменение маршрутов, политик безопасности и конфигураций без физического вмешательства.
|
||||
|
||||
4. **Безопасность на основе политик**
|
||||
> Централизованное управление доступом и правилами фильтрации трафика на уровне контроллера.
|
||||
|
||||
5. **Микросегментация сети**
|
||||
> Разделение сети на мелкие логические зоны с индивидуальными правилами доступа — повышение безопасности и управляемости.
|
||||
|
||||
|
||||
## 🧩 Виртуализация сетевых функций (NFV — Network Functions Virtualization)
|
||||
|
||||
**NFV** — это подход, при котором традиционные аппаратные сетевые устройства заменяются на программные аналоги, запускаемые в виртуализированной среде.
|
||||
|
||||
---
|
||||
|
||||
### 🔁 Что заменяется:
|
||||
|
||||
| Аппаратные устройства | Виртуальные аналоги |
|
||||
|---------------------------|----------------------------|
|
||||
| 🛣️ Маршрутизатор | Виртуальный маршрутизатор |
|
||||
| ⚖️ Балансировщик нагрузки | Виртуальный балансировщик |
|
||||
| 🔥 Фаервол | Виртуальный фаервол |
|
||||
| 📶 Оптимизатор трафика | Виртуальный оптимизатор |
|
||||
|
||||
---
|
||||
|
||||
### 🎯 Преимущества NFV:
|
||||
|
||||
- **Гибкость** — быстрая настройка и развертывание сетевых функций.
|
||||
- **Экономия** — снижение затрат за счёт отказа от дорогого специализированного оборудования.
|
||||
- **Масштабируемость** — лёгкое масштабирование при росте нагрузки.
|
||||
- **Централизация управления** — удобное обновление, мониторинг и автоматизация.
|
||||
|
||||
---
|
||||
|
||||
### 🧱 Где используется:
|
||||
|
||||
- Облачные и дата-центр инфраструктуры
|
||||
- Провайдерские сети и телеком
|
||||
- Корпоративные среды с высокой отказоустойчивостью
|
||||
|
||||
> 💡 NFV часто используется **совместно с SDN** — SDN управляет маршрутизацией, а NFV обеспечивает сетевые сервисы.
|
||||
|
||||
## 🚀 Сценарии использования NFV (Network Functions Virtualization)
|
||||
|
||||
1. **Сокращение капитальных и операционных затрат**
|
||||
> Отказ от дорогостоящего специализированного сетевого оборудования в пользу программных решений, запускаемых на стандартных серверах.
|
||||
|
||||
2. **Ускорение развертывания сетевых сервисов**
|
||||
> Быстрое масштабирование и внедрение новых функций без ожидания поставок оборудования.
|
||||
|
||||
3. **Повышение гибкости управления существующими сетевыми технологиями**
|
||||
> Лёгкая адаптация и настройка сетевых функций под текущие бизнес-задачи.
|
||||
|
||||
4. **Независимость от производителя сетевого оборудования**
|
||||
> Использование открытых решений снижает привязку к конкретному вендору, упрощает миграцию и развитие инфраструктуры.
|
||||
|
||||
|
||||
## ☁️ Частное и гибридное облако (Private & Hybrid Cloud)
|
||||
|
||||
---
|
||||
|
||||
### 🔹 Что важно помнить
|
||||
|
||||
> **Виртуализация ≠ Облако**
|
||||
> Облако — это не просто набор виртуальных машин, а модель, обладающая *определёнными характеристиками и сервисами*.
|
||||
|
||||
---
|
||||
|
||||
### 🔑 5 базовых характеристик облака:
|
||||
|
||||
1. **Самообслуживание по запросу**
|
||||
Пользователь самостоятельно запрашивает ресурсы без участия администратора.
|
||||
|
||||
2. **Широкий доступ**
|
||||
Доступ через стандартные механизмы (например, веб-интерфейс или API) из любого места.
|
||||
|
||||
3. **Объединение ресурсов**
|
||||
Использование пула ресурсов (ЦП, ОЗУ, хранилище), распределяемого между пользователями.
|
||||
|
||||
4. **Гибкость (эластичность)**
|
||||
Возможность масштабирования ресурсов по мере необходимости.
|
||||
|
||||
5. **Измеряемый сервис**
|
||||
Учёт потребления и контроль затрат: пользователи платят за то, что реально используют.
|
||||
|
||||
---
|
||||
|
||||
### 🌥️ Модели развертывания облаков:
|
||||
|
||||
#### 🟪 Частное облако (Private Cloud)
|
||||
- Полный контроль над инфраструктурой
|
||||
- Ограниченные ресурсы (только своё оборудование)
|
||||
- Требуется закупка оборудования и лицензий
|
||||
- Сервисы и поддержка разрабатываются самостоятельно
|
||||
|
||||
#### ◽ Публичное облако (Public Cloud)
|
||||
- Контроль только на уровне ВМ и приложений
|
||||
- Виртуально неограниченные ресурсы
|
||||
- Аренда ресурсов на необходимое время
|
||||
- Готовые сервисы "из коробки"
|
||||
|
||||
#### ◾ Гибридное облако (Hybrid Cloud)
|
||||
- Комбинация частного и публичного
|
||||
- Гибкое распределение задач по типу нагрузки
|
||||
- Доступ к внешним ресурсам при необходимости
|
||||
- Оптимизация затрат и удобство масштабирования
|
||||
|
||||
---
|
||||
|
||||
### ⚙️ Модели сервисов (по типу предоставления)
|
||||
|
||||
#### 🟩 IaaS (Infrastructure as a Service)
|
||||
- Пользователь управляет: ОС, сетями, ПО
|
||||
- Не управляет: физической инфраструктурой
|
||||
- Пример: развертывание виртуального сервера с Linux
|
||||
|
||||
#### ◽ PaaS (Platform as a Service)
|
||||
- Пользователь управляет: кодом, библиотеками, средой исполнения
|
||||
- Не управляет: инфраструктурой, ОС, сетью
|
||||
- Пример: развертывание Python-приложения на платформе
|
||||
|
||||
#### 🟪 SaaS (Software as a Service)
|
||||
- Пользователь использует готовое приложение
|
||||
- Не управляет: инфраструктурой, ОС, кодом
|
||||
- Пример: Google Docs, Microsoft 365, Zoom
|
||||
|
||||
---
|
||||
|
||||
> 💡 Облачные технологии позволяют гибко управлять ресурсами, снижать издержки и ускорять выпуск сервисов на рынок.
|
||||
|
||||
|
||||
## 🖥️ VDI и терминальный доступ
|
||||
**VDI (Virtual Desktop Infrastructure)** — инфраструктура виртуальных рабочих столов, позволяющая пользователям работать удалённо в безопасной среде.
|
||||
|
||||
---
|
||||
|
||||
### 🌍 Концепция удалённого рабочего стола
|
||||
|
||||
- Рабочее окружение (десктоп) развёрнуто на сервере, а пользователь получает доступ к нему через сеть.
|
||||
- Пользователь может подключаться с любого устройства (ПК, ноутбук, смартфон, thin client).
|
||||
|
||||
---
|
||||
|
||||
### ⚙️ Две основные технологии:
|
||||
|
||||
| VDI | RDS (Remote Desktop Services) |
|
||||
|-----|-------------------------------|
|
||||
| Каждому пользователю — отдельная виртуальная машина | Один сервер — несколько пользовательских сессий |
|
||||
| Высокая изоляция и гибкость | Эффективное использование ресурсов |
|
||||
| Подходит для ресурсоёмких задач | Хорош для типовых офисных приложений |
|
||||
|
||||
---
|
||||
|
||||
### 🔌 Протоколы доставки удалённого доступа:
|
||||
|
||||
- **RDP** — стандартный протокол Windows
|
||||
- **SPICE** — графически оптимизированный протокол от Red Hat
|
||||
- **VNC** — кроссплатформенный, независимый протокол
|
||||
- **X2Go** — производительный протокол на базе SSH
|
||||
- **RTSP** — используется редко, преимущественно для потоков
|
||||
|
||||
---
|
||||
|
||||
### 🌐 Портал пользователя
|
||||
|
||||
Пользователь получает доступ к своим рабочим столам через:
|
||||
|
||||
- Веб-интерфейс
|
||||
- Мобильное приложение
|
||||
- Тонкий клиент
|
||||
- Ноутбук
|
||||
---
|
||||
|
||||
### ✅ Преимущества
|
||||
|
||||
#### **VDI:**
|
||||
- Выделенная ВМ с индивидуальной настройкой
|
||||
- Не влияет на других пользователей
|
||||
- Поддержка специфичного ПО
|
||||
- Высокая конфиденциальность
|
||||
- Использование vGPU и гибкая настройка
|
||||
|
||||
#### **RDS:**
|
||||
- Одна ОС — много сессий
|
||||
- Быстрая установка и обновление
|
||||
- Высокая плотность ресурсов
|
||||
- Централизованное управление и безопасность
|
||||
- Меньшая стоимость
|
||||
|
||||
## Ключевые особенности zVirt
|
||||
|
||||
### 🔑 Основные функции
|
||||
|
||||
- **SDN (Сетевая виртуализация)**
|
||||
Аналог базовой функциональности VMware NSX
|
||||
Включает:
|
||||
- Центральный контроллер управления
|
||||
- Логическое сегментирование ВМ
|
||||
- Микросегментация (L3–L4)
|
||||
- REST-интерфейс
|
||||
- Менеджмент портов ВМ (IPAM, MAC/IP контроль)
|
||||
- Зеркалирование трафика
|
||||
- L2/L3 подключение с NAT и статической маршрутизацией
|
||||
|
||||
- **Репликация и Disaster Recovery (DR)**
|
||||
Аналог VMware SRM и vSphere Replication
|
||||
*Архитектура*:
|
||||
- Агент-отправитель (на основной площадке)
|
||||
- Контроллер репликации zVirt (в РЦОД)
|
||||
- Агент-приемник
|
||||
|
||||
*Характеристики*:
|
||||
- **5** точек восстановления
|
||||
- **>15 мин** шаг между точками
|
||||
- **15 мин (RTO)** — время восстановления
|
||||
- **до 15 мин (RPO)** — максимум потерянных транзакций
|
||||
|
||||
|
||||
- **Конвертер с VMware**
|
||||
Массовая миграция ВМ с минимальным простоем
|
||||
|
||||
| Параметр | До релиза 4.1 | С релиза 4.1 |
|
||||
|--------------|----------------------|------------------------------|
|
||||
| Миграция | 3,5 часа | 17 мин синхронизация + 6 мин |
|
||||
| Даунтайм | 3,5 часа | 6 минут |
|
||||
| Режим работы | Последовательно | Параллельно (до 20 ВМ) |
|
||||
|
||||
Reference in New Issue
Block a user