mirror of
https://github.com/ada-dmitry/ada-dmitry.github.io.git
synced 2026-09-24 01:10:35 +00:00
509 lines
29 KiB
Markdown
509 lines
29 KiB
Markdown
---
|
||
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 ВМ) |
|
||
|