mirror of
https://github.com/ada-dmitry/ada-dmitry.github.io.git
synced 2026-09-24 01:10:35 +00:00
Add lecture notes on virtualization, basic network services, backup systems, and monitoring
- Introduced comprehensive notes on virtualization, covering architecture, hypervisors, and containerization. - Added detailed lecture on basic network services including DNS, DHCP, and NTP, emphasizing their importance in IT infrastructure. - Included notes on backup systems (СРК), discussing RTO, RPO, and backup strategies. - Documented the significance of monitoring systems, differentiating between monitoring and observability, and outlining key metrics to track. - Created new markdown files for personal projects on home server setup and containerization, linking them to the main notes.
This commit is contained in:
ada
@@ -1,110 +0,0 @@
|
||||
---
|
||||
title: Новое начало
|
||||
layout: single
|
||||
---
|
||||
|
||||
Доброго вечера, коллеги!
|
||||
|
||||
Перейдем таки к конкретике:
|
||||
Изначально, я хотел старый компьютер превратить в сервер (ну вот страсть у меня появилась, ничего не поделать)
|
||||
|
||||
Взял я несколько старых ПК, в т.ч. с дачи, вытащил из них всё, что можно вытащить.
|
||||
Собрал, по итогу, страшную штуку, которую положил себе под кровать в общежитии (поменял ещё кулеры, чтоб не шумел), но надежды не увенчались успехом, соседу не понравился шум ПК(хоть его и не было слышно...). Ладно, подумал было я, сервер, работающий только днем - не сервер.
|
||||
|
||||
Отложил я идею, все комплектующие из сервера в основной ПК, все харды (HDD), оперативную память, сделал себе убер-машину.
|
||||
|
||||
Прошло пару месяцев и вот я загорелся идеей купить мини-пк (те, что ставят в офисе обычным работника, которым не нужны огромные мощности, но вашна компактность) и на базе него сделать домашний сервер.
|
||||
|
||||
Спустя некоторое время поисков, я нашел хороший вариант, а именно - китайский мини-пк с неплохими характеристиками и аж 4-мя слотами под m.2 SSD (потом расскажу, зачем и что это вообще такое)
|
||||
|
||||
|
||||
|
||||
Значит, недолго думая, я его заказал, он пришел, круто, классно, что дальше?
|
||||
|
||||
А дальше, мы начинаем новую главу нашего рассказа:
|
||||
|
||||
## Proxmox
|
||||
|
||||
Как я уже рассказывал, существует несколько видов [[Коробочки-коробочки...#Гипервизоры|гипервизоров]], мы поставим на наш сервер гипервизор первого типа, т.е. непосредственно на "железо".
|
||||
Это нам позволяет независимо друг от друга запускать ВМ-ки и контейнеры.
|
||||
Что такое конкретно ***Proxmox***? Это Open-Source решение для виртуализации, т.е. бесплатное, т.е. разрабатывается открытым сообществом (ну, сейчас уже не совсем, но так или иначе).
|
||||
Почему именно это решение? Есть oVirt, который тоже бесплатный, но это прям совсем Enterprise решение, там очень много фишек, которые обычному пользователю не нужны, да и Proxmox с этой точки зрения более *коробочное* решение.
|
||||
|
||||
|
||||
|
||||
Вот как выглядит установленный Proxmox (ну, точнее уже с несколькими развернутыми контейнерами).
|
||||
Тут вы сможете обнаружить список уже развернутых систем, краткую сводку по системе и много-много другое. Интерфейс слегка страшный, но только на первый взгляд.
|
||||
|
||||
Идем дальше, кратко расскажу, как я (и вы) получили доступ к этому сайту (у меня есть ещё несколько, но они скрыты от публики)
|
||||
|
||||
Представьте, у вас есть комьютер в домашней сети. У него есть опредлеленный ip-адрес (его ему выдал DHCP-сервер, но об этом в другой раз) формата `192.168.*.*`, это его внутренний ip, т.е. он за NAT'ом
|
||||
|
||||
> [!info] NAT
|
||||
> NAT (Network Address Translation) — это как переводчик между твоей домашней сетью и Интернетом.
|
||||
> Внутри дома у всех устройств есть свои «внутренние» IP-адреса, которые снаружи никто не видит.
|
||||
> Когда ты выходишь в Интернет, роутер меняет этот адрес на один «внешний» общий для всей сети.
|
||||
|
||||
Если ещё проще, то он просто маскирует твой личный ip под общий для всей сети. Более того, ip твоего роутера тоже не статичный *зачастую*, а динамический, выдаваемый провайдером.
|
||||
|
||||
---
|
||||
|
||||
Итого, у нашего сервера постоянно меняющийся ip, к которому мы не можем обращаться из интернета (это круто, да, безопасность, но вопрос об удаленном доступе уходит сам собой:)).
|
||||
Что делать? Вариантов несколько, но практически везде, кодовое слово "*туннель*":
|
||||
|
||||
1) Tailscale - это готовое решения для создания виртуальной локальной сети (каждому устройству в сети выдается "виртуальный ip")
|
||||
|
||||
***Плюсы***: Быстро, бесплатно, почти автоматически.
|
||||
|
||||
|
||||
***Минусы***: Никакой гибкости, решение только для индивидуального доступа (вот такой сайт не сделать), безопасность перекладывается на внешнего вендора.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
2) VPS - сервер
|
||||
|
||||
|
||||
**Решение**: Мы покупаем маленький внешний сервер у провайдера (в моем случае Timecloud.Web, *не реклама*, у них явно маркетинг не на мой канал направлен), у него есть белый IP.
|
||||
Что дальше? А дальше, мы поднимаем на этом VPS "обратный прокси", т.е. веб-сервер, но который не сам по себе будет выводить картинку, а "переадресовывать" запросы пользователя на наш внутренний сервер.
|
||||
|
||||
|
||||
***Плюсы***: Гибко, интересно.
|
||||
|
||||
|
||||
***Минусы***: Стоит денег, сложно в настройке, безопасность ложится на нас.
|
||||
|
||||
> VPS (Virtual Private Server) — это как отдельный «компьютер» внутри большого компьютера, который тебе сдают в аренду.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
Как вы понимаете, я - мазозист и выбрал VPS (ну, ещё мне нужен был вывод сайта в публичное поле).
|
||||
|
||||
Но вот проблема, наш VPS точно так же не видит нащ сервер, что делать? ТУННЕЛЬ!
|
||||
|
||||
Мы поднимаем буквально VPN (Virtual Private Network) - проще говоря, делаем такой же tailscale, но сами)
|
||||
|
||||
Вот поднимаем туннель, т.е. зашифрованное соединение между двумя клиентами (peer2peer), они друг друга видят, притом VPS может свободно обращаться устройствам внутри сервера, что нам и нужно.
|
||||
|
||||
Не буду углубляться в детали происходящего, но я использую WireGuard, как туннель.
|
||||
|
||||
|
||||
|
||||
Притом, что удобно, мы этот самый WG используем и как способ защиты от нежелательных гостей, ведь мы можем настроить наши сайты так, чтобы они пускали к себе только пользователей, которые тоже являются участниками это приватной сети. Кайфы, да?
|
||||
Отвечу за вас, да!
|
||||
|
||||
У нас есть классный способ "проникать" на наши ресурсы, притом четко разграничивать доступы (вы этот сайт видите, а некоторые не видите).
|
||||
|
||||
Последнее, что я опишу в этой огромной статье - это домен - dg.ada-dev.ru (dg - digitalgarden).
|
||||
В данном случае, это поддомен домена ada-dev.ru, который зарегистрирован на меня в том же TimeCloud.Web.
|
||||
На него я выписываю сертификаты, поэтому на вас не ругается браузер, когда вы заходите на этот сайт по http**s**, что делает наше с вами соединение безопасным)
|
||||
|
||||
На этом на сегодня все, рассказывайте, что было понятно, что не понятно, что пояснить, куда что добавить и о чем сделать следующую статью:
|
||||
1) Продолжаем про сервер
|
||||
2) Поговорим о сторонних вещах (DNS, DHCP, или что-то ещё)
|
||||
|
||||
Всем спокойной ночи и прекрасных выходных!
|
||||
|
||||
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: Летняя IT-школа КРОК
|
||||
layout: single
|
||||
---
|
||||
|
||||
Я прошел летнюю школу по направлению System-инженер, поэтому хочу поделиться своими конспектами. Конечно, это не заменит очное обучение там (а это было круто), но познакомиться с профессией системного инженера поможет)
|
||||
|
||||
P.s. Я буду постепенно выкладывать, потому что преобразовывать заметки из Obsidian в формат для сайта - штука трудозатратная)
|
||||
|
||||
## 📘 Теория
|
||||
1) [Что такое IT-инфраструктура]({% link _notes/IT-School/Lecture/02-it_infra.md %})<br>
|
||||
2) [Инфраструктура на уровне железа]({% link _notes/IT-School/Lecture/03-bare-metal.md %})<br>
|
||||
3) [Автоматизация в программной инфраструктуре]({% link _notes/IT-School/Lecture/04-auto.md %})<br>
|
||||
4) [Введение в виртуализацию]({% link _notes/IT-School/Lecture/05-vm.md %})<br>
|
||||
5) [Базовые сетевые службы]({% link _notes/IT-School/Lecture/06-bss.md %})<br>
|
||||
6) [Системы резервного копирования (СРК)]({% link _notes/IT-School/Lecture/07-srk.md %})<br>
|
||||
7) [Системы мониторинга]({% link _notes/IT-School/Lecture/08-mon.md %}) <br>
|
||||
|
||||
## 🧠 Полезные заметки <br>
|
||||
- [Отказоустойчивость VS Высокая доступность]({% link _notes/IT-School/Additional/01-havs.md %}) <br>
|
||||
- [SLA, SLO, SLI]({% link _notes/IT-School/Additional/02-slaoi.md %}) <br>
|
||||
- [Метрики и алерты] <br>
|
||||
- [Split-brain] <br>
|
||||
- [Геораспределённые кластеры и ЦОД] <br>
|
||||
- [Виды кластеров высокой доступности] <br>
|
||||
- [RAID — Redundant Array of Independent Disks] <br>
|
||||
- [Публичные выступления]
|
||||
|
||||
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
title: Отказоустойчивость VS Высокая доступность
|
||||
---
|
||||
|
||||
В мире ИТ надёжность систем — критически важная задача. Часто используют два термина: **отказоустойчивость** и **высокая доступность**. Несмотря на схожесть целей, это разные подходы.
|
||||
|
||||
---
|
||||
|
||||
### 🔹 Отказоустойчивость (Fault Tolerance)
|
||||
|
||||
Это способность системы **продолжать работу без перерыва**, даже если откажет один или несколько компонентов.
|
||||
|
||||
Такой эффект достигается за счёт **резервных узлов**, работающих параллельно.
|
||||
|
||||
**Пример:** RAID-массив, кластер Active-Active.
|
||||
|
||||
[[RAID — Redundant Array of Independent Disks]]
|
||||
|
||||
---
|
||||
|
||||
### 🔹 Высокая доступность (High Availability)
|
||||
|
||||
Это стремление к **минимальному времени простоя**. Если один компонент выходит из
|
||||
строя, другой может заменить его, но с небольшой задержкой.
|
||||
|
||||
**Пример:** автоматическое переключение на резервный сервер в кластере Active-Passive.
|
||||
|
||||
---
|
||||
|
||||
### 🔸 Ключевое различие:
|
||||
|
||||
- Отказоустойчивая система не прерывает работу вовсе.
|
||||
|
||||
- Высокодоступная система может иметь **короткий простой**, но быстро восстанавливается.
|
||||
@@ -1,56 +0,0 @@
|
||||
|
||||
## ✅ SLI — Service Level Indicator
|
||||
|
||||
**Показатель уровня сервиса.**
|
||||
|
||||
Что мы измеряем?
|
||||
|
||||
📌 Примеры:
|
||||
|
||||
- Доля успешных запросов
|
||||
|
||||
- Среднее время отклика
|
||||
|
||||
- Аптайм за 30 дней
|
||||
|
||||
---
|
||||
|
||||
## 🎯 SLO — Service Level Objective
|
||||
|
||||
**Целевой уровень показателя.**
|
||||
|
||||
Какого значения мы хотим достичь?
|
||||
|
||||
📌 Примеры:
|
||||
|
||||
- 99.9% успешных запросов
|
||||
|
||||
- ≤ 200 мс отклик в 95% случаев
|
||||
|
||||
---
|
||||
|
||||
## 🤝 SLA — Service Level Agreement
|
||||
|
||||
**Соглашение об уровне сервиса.**
|
||||
|
||||
Юридическое обязательство перед клиентом.
|
||||
|
||||
📌 Включает:
|
||||
|
||||
- SLO (цели)
|
||||
|
||||
- Санкции за нарушения
|
||||
|
||||
- Обязанности сторон
|
||||
|
||||
---
|
||||
|
||||
## 📊 Связь:
|
||||
|
||||
```
|
||||
SLI → что измеряем
|
||||
|
||||
SLO → цель показателя
|
||||
|
||||
SLA → договор с клиентом
|
||||
```
|
||||
@@ -1,200 +0,0 @@
|
||||
---
|
||||
title: Что такое IT-инфраструктура
|
||||
---
|
||||
|
||||
|
||||
👨🏫 *Лектор: Дмитрий Рябов*
|
||||
|
||||
Эксперт Департамента инфраструктурных решений и сервисов
|
||||
|
||||
Летняя школа «System-инженер»
|
||||
|
||||
---
|
||||
|
||||
## 📌 Определение
|
||||
|
||||
**ИТ-инфраструктура** — совокупность физических и программных компонентов, обеспечивающих бесперебойную, безопасную и эффективную работу ИТ-среды предприятия.
|
||||
|
||||
Она включает:
|
||||
|
||||
- Серверы и вычислительные узлы
|
||||
|
||||
- Сетевое оборудование и каналы связи
|
||||
|
||||
- Системы хранения данных (СХД)
|
||||
|
||||
- Базовые и инфраструктурные программные сервисы
|
||||
|
||||
- Средства безопасности и мониторинга
|
||||
|
||||
> 🧠 Является **основой функционирования всех бизнес-приложений и сервисов**.
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Основные задачи ИТ-инфраструктуры
|
||||
|
||||
1. 🔒 **Бесперебойность и безопасность** — защита данных и стабильность работы критически важных систем
|
||||
|
||||
2. ⚙️ **Производительность и экономия** — снижение затрат и оптимизация операций
|
||||
|
||||
3. 🤝 **Связь и сотрудничество** — обеспечение взаимодействия пользователей и сервисов
|
||||
|
||||
4. 📈 **Оптимизация ресурсов** — устранение избыточности и повышение эффективности
|
||||
|
||||
5. 🔄 **Гибкость** — адаптация к изменениям и масштабируемость
|
||||
|
||||
6. 💸 **Снижение затрат и рисков** — управление рисками при внедрении новых решений
|
||||
|
||||
---
|
||||
|
||||
## 🧱 Аппаратная часть
|
||||
|
||||
Физическая основа ИТ-инфраструктуры:
|
||||
|
||||
- 🖥️ **Серверы и рабочие станции** — производительные системы для вычислений и обслуживания сервисов
|
||||
|
||||
- 🌐 **Сетевое оборудование** — маршрутизаторы, коммутаторы, точки доступа, межсетевые экраны
|
||||
|
||||
- 🏢 **ЦОД (центры обработки данных)** — помещения с системами питания, охлаждения, безопасности
|
||||
|
||||
- 🖨️ **Периферия** — принтеры, сканеры, ИБП, терминалы
|
||||
|
||||
---
|
||||
|
||||
## 🌐 Сетевая часть
|
||||
|
||||
Обеспечивает связность и обмен данными:
|
||||
|
||||
- **Оборудование**: маршрутизаторы, коммутаторы, точки доступа
|
||||
|
||||
- **Протоколы**: TCP/IP, Ethernet, VLAN, VPN
|
||||
|
||||
- **Доступы**: интернет, облачные ресурсы, корпоративная сеть
|
||||
|
||||
---
|
||||
|
||||
## 💽 Программная часть
|
||||
|
||||
### 1. Операционные системы
|
||||
|
||||
- Windows Server, Linux, гипервизоры (ESXi, KVM и др.)
|
||||
|
||||
### 2. Инфраструктурные сервисы
|
||||
|
||||
- ✅ **Служба каталога (LDAP/AD)** — управление пользователями, аутентификация
|
||||
|
||||
- 🌐 **DNS** — разрешение доменных имён
|
||||
|
||||
- 🛜 **DHCP** — автоматическая настройка IP-адресов
|
||||
|
||||
- ⏱ **NTP** — синхронизация времени
|
||||
|
||||
- 📧 **Почтовые и коммуникационные службы**
|
||||
|
||||
- 🖨 **Служба печати**
|
||||
|
||||
- 🗂 **Файловая система**
|
||||
|
||||
- 💾 **Резервное копирование и восстановление**
|
||||
|
||||
### 3. Системы безопасности
|
||||
|
||||
- Антивирусы, DLP, межсетевые экраны, IDS/IPS, шифрование
|
||||
|
||||
---
|
||||
|
||||
## 🧩 Структура программной инфраструктуры
|
||||
|
||||
| Инструмент | Назначение |
|
||||
|----------------------------------|----------------------------------------------|
|
||||
| Платформа виртуализации / VDI | Запуск виртуальных машин |
|
||||
| DHCP | Подключение к локальной сети (ЛВС) |
|
||||
| DNS, NTP | Обнаружение и синхронизация в сети |
|
||||
| Служба каталога | Аутентификация пользователей и устройств |
|
||||
| Центр сертификации | Безопасность и шифрование |
|
||||
| Управление конфигурациями | Обновления, установка ПО |
|
||||
| Файловая система | Хранение и доступ к данным |
|
||||
| Служба печати | Сетевой доступ к принтерам |
|
||||
| Почта/мессенджер | Коммуникация внутри и вне компании |
|
||||
| Мониторинг и СРК | Контроль состояния, сбои и уведомления |
|
||||
| Резервное копирование | Восстановление в случае сбоев |
|
||||
|
||||
---
|
||||
|
||||
## ☁️ Модели ИТ-инфраструктуры
|
||||
|
||||
1. **On-Premise (традиционная)**
|
||||
|
||||
Полный контроль, оборудование на стороне организации
|
||||
|
||||
2. **Облачная**
|
||||
|
||||
Использование ресурсов внешнего облака (IaaS, PaaS, SaaS)
|
||||
|
||||
3. **Гибридная**
|
||||
|
||||
Комбинация локальных и облачных решений
|
||||
|
||||
---
|
||||
|
||||
## 🛠 Этапы создания ИТ-инфраструктуры
|
||||
|
||||
1. **Анализ и планирование**
|
||||
|
||||
Определение потребностей, целей, бюджета, масштабов
|
||||
|
||||
2. **Проектирование архитектуры**
|
||||
|
||||
Выбор платформ, протоколов, расчёт ресурсов
|
||||
|
||||
3. **Развёртывание и настройка**
|
||||
|
||||
Монтаж, установка, конфигурация всех компонентов
|
||||
|
||||
4. **Тестирование и оптимизация**
|
||||
|
||||
Проверка отказоустойчивости, безопасности, производительности
|
||||
|
||||
---
|
||||
|
||||
## 🧩 Актуальные задачи и эффекты от внедрения
|
||||
|
||||
- Централизация, миграции и консолидация систем
|
||||
|
||||
- Импортозамещение ПО
|
||||
|
||||
- Повышение отказоустойчивости
|
||||
|
||||
- Снижение затрат на поддержку
|
||||
|
||||
- Упрощение администрирования
|
||||
|
||||
- Рост гибкости и готовности к масштабированию
|
||||
|
||||
---
|
||||
|
||||
## 🏗️ Типы проектов
|
||||
|
||||
- Проектирование/внедрение новых служб
|
||||
|
||||
- Миграции и консолидация инфраструктуры
|
||||
|
||||
- Технический аудит и консалтинг
|
||||
|
||||
- Поддержка интеграционных решений
|
||||
|
||||
- Модернизация и импортозамещение
|
||||
|
||||
- Разделение/слияние инфраструктуры
|
||||
|
||||
- Техническая поддержка и сопровождение
|
||||
|
||||
---
|
||||
|
||||
## ✅ Итоги
|
||||
|
||||
**ИТ-инфраструктура — стратегический актив компании.**
|
||||
|
||||
Она не просто "техническая база", а фундамент для цифровой трансформации, роста эффективности, устойчивости бизнеса и реагирования на вызовы рынка.
|
||||
|
||||
---
|
||||
@@ -1,164 +0,0 @@
|
||||
---
|
||||
title: Инфраструктура на уровне железа
|
||||
---
|
||||
|
||||
👨🏫 *Антон Иванов*
|
||||
|
||||
Руководитель группы инженеров поддержки инфраструктурного ПО
|
||||
|
||||
Летняя школа «System-инженер»
|
||||
|
||||
---
|
||||
|
||||
## 📐 Слои ИТ-инфраструктуры (условный «слоёный пирог»)
|
||||
|
||||
- **Прикладной уровень** — ERP, CRM, почта, офис, ВКС
|
||||
|
||||
- **Платформенный уровень** — виртуализация, контейнеризация, СУБД
|
||||
|
||||
- **Системный уровень** — ОС, службы (DNS, DHCP, AD), безопасность
|
||||
|
||||
- **Аппаратный уровень** — серверы, СХД, SAN, сеть, СКС, ЦОД, ИБП, кондиционирование
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Основные элементы железной инфраструктуры
|
||||
|
||||
### 🖥️ Серверы — ядро вычислений
|
||||
|
||||
- Постоянно включены, предназначены для длительной нагрузки
|
||||
|
||||
- Отличия от ПК:
|
||||
|
||||
- Резервные блоки питания и вентиляторы
|
||||
|
||||
- 2+ процессора, объёмная ОЗУ
|
||||
|
||||
- Форм-фактор: rackmount
|
||||
|
||||
- Предназначены для запуска сервисов, баз данных, виртуальных машин и пр.
|
||||
|
||||
### 💽 СХД — хранение данных
|
||||
|
||||
- Не размещают данные на самих серверах: используется **выделенное хранилище**
|
||||
|
||||
- Это массив дисков (HDD/SSD), объединённых в [[RAID — Redundant Array of Independent Disks|RAID]]
|
||||
|
||||
- Типы подключения:
|
||||
|
||||
- **DAS** — прямое (к одному серверу)
|
||||
|
||||
- **SAN** — выделенная сеть
|
||||
|
||||
- **NAS** — файловый доступ по IP
|
||||
|
||||
Подробнее про [[СХД — Системы хранения данных]]
|
||||
|
||||
### 🔗 SAN — сеть хранения данных
|
||||
|
||||
- Соединяет серверы и СХД
|
||||
|
||||
- Особенности:
|
||||
|
||||
- Оптические кабели, трансиверы, оптические коммутаторы
|
||||
|
||||
- Протоколы: **Fibre Channel (FC)**, **iSCSI**
|
||||
|
||||
- Преимущества: высокая скорость, низкие задержки, надёжность
|
||||
|
||||
Подробнее про [[Сеть хранения данных (SAN — Storage Area Network)]]
|
||||
|
||||
### 🔁 Резервное копирование
|
||||
|
||||
- Зачем:
|
||||
|
||||
- Защита от сбоев, ошибок, атак, потерь
|
||||
|
||||
- Решения:
|
||||
|
||||
- **Ленточные библиотеки** — дёшево, надёжно, но медленно
|
||||
|
||||
- **Дисковые системы** — быстрее, с дедупликацией и сжатием
|
||||
|
||||
### 🏢 ЦОД — дом для всей инфраструктуры
|
||||
|
||||
- Помещение с серверами, СХД, сетями, системами охлаждения, безопасности, питания
|
||||
|
||||
- Используются несколько площадок (актив-актив, актив-пассив)
|
||||
|
||||
- Данные реплицируются → отказоустойчивость
|
||||
|
||||
Подробнее про [[ЦОД - Центр обработки данных]]
|
||||
|
||||
---
|
||||
|
||||
## ❗ SPOF — Single Point of Failure
|
||||
|
||||
> Единая точка отказа — компонент, при сбое которого рушится вся система
|
||||
|
||||
Решение: дублирование, кластеризация, отказоустойчивость.
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Анатомия сервера x86
|
||||
|
||||
### 🧠 Вычислительная подсистема
|
||||
|
||||
- Процессоры (часто 2+), соединённые по **UPI**
|
||||
|
||||
- Память DDR (в нескольких каналах)
|
||||
|
||||
### 💾 Дисковая подсистема
|
||||
|
||||
- RAID-контроллеры: аппаратные и программные
|
||||
|
||||
- Кэш + аккумулятор SuperCap
|
||||
|
||||
- Диски: **SAS**, **SATA**, **NVMe**
|
||||
|
||||
### 💳 PCIe-карты (расширения)
|
||||
|
||||
- **NIC** — сетевые карты (Ethernet, TCP/IP)
|
||||
|
||||
- **HBA** — адаптеры для SAN (Fibre Channel)
|
||||
|
||||
- **GPU/ASIC** — ускорение ML, AI, вычислений
|
||||
|
||||
Подробнее про [[PCI-карты (карты расширения)]]
|
||||
|
||||
Подробнее про [[Сервер x86]]
|
||||
|
||||
---
|
||||
|
||||
## 💾 Типы систем хранения данных (СХД)
|
||||
|
||||
| Тип | Протоколы | Назначение |
|
||||
|------------|----------------|-------------------------------------------------|
|
||||
| **Блочные** | SCSI, iSCSI | Высокопроизводительные задачи, виртуализация |
|
||||
| **Файловые** | NFS, SMB/CIFS | Общие ресурсы, сетевые папки |
|
||||
| **Объектные**| S3, Swift | Архивы, большие объёмы неструктурированных данных |
|
||||
|
||||
---
|
||||
|
||||
## 📉 RTO и RPO
|
||||
|
||||
- **RPO (Recovery Point Objective)** — сколько данных допустимо потерять (в минутах/часах)
|
||||
|
||||
- **RTO (Recovery Time Objective)** — за сколько система должна восстановиться
|
||||
|
||||
> 💡 Ключевые метрики при проектировании резервного копирования и отказоустойчивости
|
||||
|
||||
---
|
||||
|
||||
## ✅ Итоги
|
||||
|
||||
- Железо — основа ИТ-инфраструктуры
|
||||
|
||||
- Серверы ≠ место для хранения данных → для этого есть СХД
|
||||
|
||||
- Сеть хранения и резервные решения повышают отказоустойчивость
|
||||
|
||||
- Архитектура должна быть спроектирована без SPOF
|
||||
|
||||
- Понимание уровня "железа" важно даже для тех, кто работает на уровне софта
|
||||
|
||||
@@ -1,90 +0,0 @@
|
||||
---
|
||||
title: Автоматизация в программной инфраструктуре
|
||||
---
|
||||
|
||||
> 👨🏫 Лектор: *Дмитрий Ширяев* — старший системный инженер (CROC)
|
||||
|
||||
---
|
||||
|
||||
## Что такое DevOps?
|
||||
|
||||
**DevOps** — это *методология и культура взаимодействия* между разработкой (Dev) и эксплуатацией (Ops), направленная на ускорение жизненного цикла программного обеспечения: от написания кода до его эксплуатации и сопровождения.
|
||||
|
||||
> 💡 DevOps — не только про разработку, но и про автоматизацию, сопровождение, обновления и масштабирование.
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Зачем автоматизировать инфраструктуру?
|
||||
|
||||
Автоматизация необходима для:
|
||||
|
||||
1. 📉 Снижения трудозатрат:
|
||||
- на установку и конфигурирование ПО
|
||||
- на эксплуатацию и сопровождение
|
||||
|
||||
2. 🛡️ Снижения рисков:
|
||||
- появления ошибок при ручных действиях
|
||||
- простоев и сбоев при обновлениях
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Что можно автоматизировать?
|
||||
|
||||
Объекты автоматизации программной инфраструктуры:
|
||||
|
||||
1. ⚙️ Инсталляция ПО
|
||||
2. 🧪 Тестирование ПО
|
||||
3. 🧩 Конфигурирование
|
||||
4. 🛠️ Поиск и устранение проблем
|
||||
5. 📈 Мониторинг
|
||||
6. 📚 Актуализация документации
|
||||
|
||||
---
|
||||
|
||||
## ⚙️ Инструменты автоматизации
|
||||
|
||||
- 🧩 Скрипты: `bash`, `PowerShell`, `python`, `go` и др.
|
||||
- 🛠️ Системы управления конфигурациями:
|
||||
- Microsoft SCCM
|
||||
- Ansible
|
||||
- Chef
|
||||
- Salt Stack
|
||||
- Puppet
|
||||
- 🗂️ Системы управления версиями: `git`, `svn`
|
||||
- 🧱 Подход *Infrastructure as Code* (IaC)
|
||||
- 🤖 Искусственный интеллект и нейросети:
|
||||
- прогнозирование сбоев
|
||||
- автоматическое устранение ошибок
|
||||
- генерация конфигураций
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Основные инструменты в команде
|
||||
|
||||
- 📚 **База знаний** — централизованное хранилище инструкций и best practices
|
||||
- 🧪 **Тестовые среды** — безопасное тестирование конфигураций до продакшна
|
||||
- 📦 **Git-репозитории со скриптами** — контроль версий и коллективная работа
|
||||
- 🤖 **CrocGPT** — ИИ-инструмент для генерации конфигураций, анализа логов, помощи в разработке
|
||||
|
||||
---
|
||||
|
||||
## 🆚 Ansible vs Chef
|
||||
|
||||
- **Ansible**:
|
||||
- *Agentless* — не требует установки агента
|
||||
- Использует SSH и YAML
|
||||
- Требует:
|
||||
- сетевую доступность узлов
|
||||
- установленный Python
|
||||
|
||||
- **Chef**:
|
||||
- Требует агента на каждом узле (Chef Client)
|
||||
- Использует Ruby DSL для описания конфигураций
|
||||
- Централизованное управление через Chef Server
|
||||
|
||||
---
|
||||
|
||||
## 🧠 P.s.
|
||||
|
||||
- Автоматизация — это не одноразовый процесс, а **непрерывное улучшение**.
|
||||
- Инструменты могут отличаться, но цель всегда одна — **сделать инфраструктуру управляемой, воспроизводимой и отказоустойчивой**.
|
||||
@@ -1,508 +0,0 @@
|
||||
---
|
||||
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 ВМ) |
|
||||
|
||||
@@ -1,166 +0,0 @@
|
||||
---
|
||||
title: Базовые сетевые службы
|
||||
---
|
||||
|
||||
👨🏫 *Лектор: Никита Ефимов*
|
||||
Системный инженер департамента инфраструктурных решений и сервисов <br>
|
||||
Летняя школа «System-инженер»
|
||||
|
||||
---
|
||||
## ⚙️ Роль сетевых служб в инфраструктуре
|
||||
|
||||
**Без них ничего не работает:**
|
||||
|
||||
- ❌ Невозможно запомнить все IP → нужен **DNS**
|
||||
- ❌ Ручная настройка сетей → нужен **DHCP**
|
||||
- ❌ Много паролей → нужна **служба каталога**
|
||||
- ❌ Нет корректного анализа логов → нужен **NTP**
|
||||
- ❌ Совместная работа — кошмар
|
||||
|
||||
> 🧠 При сбоях в этих службах возникает множество "необъяснимых" проблем: недоступные сервисы, ошибки авторизации, разрыв сессий, сбои CI/CD, нарушения аудита.
|
||||
|
||||
---
|
||||
|
||||
# 📚 Служба каталога
|
||||
|
||||
## 🎯 Назначение
|
||||
- Централизованное хранение и управление учетными записями пользователей, групп и устройств
|
||||
|
||||
- Аутентификация и авторизация в домене (логины, пароли, доступы)
|
||||
|
||||
## ➕ Дополнительные функции <br>
|
||||
- Интеграция с другими сервисами (DNS, принт-сервер, файловые шары) <br>
|
||||
- Применение групповых политик (GPO) — настройка рабочих станций централизованно <br>
|
||||
- Управление безопасностью: контроль доступа, политики паролей, аудита
|
||||
|
||||
## 🧱 Ключевые понятия <br>
|
||||
- **Лес (Forest)** — логическая граница всей инфраструктуры службы каталога <br>
|
||||
- **Домен (Domain)** — единица управления пользователями и ресурсами <br>
|
||||
- **Контроллер домена (DC)** — сервер, предоставляющий каталог и аутентификацию <br>
|
||||
- **OU (организационные подразделения)** — для логического структурирования объектов <br>
|
||||
- **Доверительные отношения** — связь между доменами, разрешающая доступ между ними <br>
|
||||
- **Kerberos** — протокол безопасной аутентификации с использованием билетов <br>
|
||||
- **LDAP** — протокол для поиска и изменения данных в каталоге
|
||||
|
||||
|
||||
|
||||
## 🛠 Что важно при проектировании <br>
|
||||
- Архитектура (лес, домены, сайты) <br>
|
||||
- Модель управления и администрирования <br>
|
||||
- Интеграции с внешними системами <br>
|
||||
- Объёмы миграции при переходе с другого решения
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 🌐 DNS — служба разрешения доменных имён
|
||||
|
||||
## 🎯 Основное назначение
|
||||
|
||||
- Преобразование доменных имён в IP-адреса (и обратно)
|
||||
|
||||
- Обнаружение сервисов и маршрутизация трафика
|
||||
|
||||
|
||||
|
||||
## 🧱 Ключевые понятия
|
||||
|
||||
- **DNS-сервер** — хранит зоны и обслуживает запросы <br>
|
||||
- **Резолвер (resolver)** — клиент, который запрашивает имя <br>
|
||||
- **Зоны** — области пространства имён (forward/reverse, primary/secondary, AD-интегрированные) <br>
|
||||
- **Типы серверов** — корневой, авторитативный, кэширующий
|
||||
|
||||
## 🔍 Популярные типы записей
|
||||
|
||||
- `A` — IPv4-адрес хоста <br>
|
||||
- `AAAA` — IPv6-адрес <br>
|
||||
- `PTR` — обратное соответствие IP → имя <br>
|
||||
- `MX` — почтовый сервер домена <br>
|
||||
- `CNAME` — псевдоним <br>
|
||||
- `TXT` — SPF, DKIM, верификация <br>
|
||||
- `NS` — указывает, кто отвечает за зону <br>
|
||||
- `SOA` — основная информация о зоне (сервер, TTL, серийный номер)
|
||||
|
||||
## 🛠 Особенности проектирования
|
||||
|
||||
- Разделение внешней и внутренней зон (Split DNS) <br>
|
||||
- Делегирование и репликация зон <br>
|
||||
- Безопасность (защита от подмены DNS, ограничение зон) <br>
|
||||
- Схема разрешения имён (например, через Root Hints или DNS Forwarders)
|
||||
|
||||
---
|
||||
|
||||
# 📡 DHCP — динамическая конфигурация узлов
|
||||
|
||||
## 🎯 Назначение
|
||||
|
||||
- Автоматическая выдача IP-адресов и других параметров (маска, шлюз, DNS, PXE и пр.)
|
||||
|
||||
## 🔁 DORA: как работает
|
||||
|
||||
1. **Discover** — клиент ищет DHCP-сервер <br>
|
||||
2. **Offer** — сервер предлагает свободный IP <br>
|
||||
3. **Request** — клиент запрашивает выбранный IP <br>
|
||||
4. **Acknowledge** — сервер подтверждает и назначает IP
|
||||
|
||||
> Использует протокол UDP (порты 67/68), часто работает через широковещательные пакеты.
|
||||
|
||||
|
||||
|
||||
## 🧱 Основные понятия
|
||||
|
||||
- **Область DHCP** — диапазон адресов, который выдаёт сервер <br>
|
||||
- **Ретранслятор (DHCP Relay)** — пересылает запросы между подсетями <br>
|
||||
- **Резервирование** — закрепление IP за конкретным устройством (по MAC-адресу) <br>
|
||||
- **Аренда** — IP выдаётся на ограниченное время (с возможностью продления)
|
||||
|
||||
## 🛠 Что учитывать
|
||||
|
||||
- Топология сети: расположение клиентов и серверов <br>
|
||||
- Надёжность: резервные DHCP, ретрансляторы <br>
|
||||
- Интеграция с DNS — автоматическая регистрация имён <br>
|
||||
- Защита от спуфинга (например, DHCP Snooping)
|
||||
|
||||
---
|
||||
|
||||
# ⏱️ NTP — служба времени
|
||||
|
||||
## 🎯 Назначение
|
||||
|
||||
- Синхронизация системных часов на всех устройствах в сети <br>
|
||||
- Критично для: Kerberos, журналов событий, мониторинга, расследования инцидентов
|
||||
|
||||
## 🧱 Основные понятия
|
||||
|
||||
- **Stratum** — уровень иерархии (Stratum 0 — эталонные часы) <br>
|
||||
- **NTP-сервер и клиент** — один задаёт время, другой получает <br>
|
||||
- **Дрейф времени** — расхождение часов без синхронизации
|
||||
|
||||
## ➕ Дополнительно
|
||||
|
||||
- Чаще всего используется встроенный Windows Time (w32time) <br>
|
||||
- Kerberos требует расхождения ≤ 5 минут <br>
|
||||
- NTP-сервер может быть внешним (например, `time.windows.com`) или локальным (на КД)
|
||||
|
||||
## 🛠 Что учитывать
|
||||
|
||||
- Требования к точности (мс или секунды) <br>
|
||||
- Отказоустойчивость (несколько источников) <br>
|
||||
- Синхронизация всей инфраструктуры — от доменов до рабочих станций
|
||||
|
||||
---
|
||||
|
||||
## 🧠 Вывод
|
||||
|
||||
Базовые сетевые службы — фундамент цифровой инфраструктуры:
|
||||
|
||||
| Служба | Назначение |
|
||||
|----------------|----------------------------------------------------------------------------|
|
||||
| Каталог (AD/LDAP) | Аутентификация, учётки, политики, безопасность |
|
||||
| DNS | Разрешение имён, обнаружение сервисов |
|
||||
| DHCP | Быстрая настройка IP, управление адресным пространством |
|
||||
| NTP | Единое время в сети, корректность логов, безопасность (Kerberos) |
|
||||
|
||||
> 💬 Пользователи не замечают этих служб — пока они работают. Но без них сеть перестаёт быть сетью.
|
||||
@@ -1,131 +0,0 @@
|
||||
---
|
||||
title: Системы резервного копирования (СРК)
|
||||
---
|
||||
|
||||
**Источник:** Летняя Школа «System-инженер»
|
||||
|
||||
**Спикер:** Антон Иванов, Руководитель группы инженеров поддержки инфраструктурного ПО
|
||||
|
||||
---
|
||||
|
||||
## 📉 Причины отказа ИТ-инфраструктуры
|
||||
|
||||
- Аппаратные сбои <br>
|
||||
- Ошибки ПО <br>
|
||||
- Человеческий фактор <br>
|
||||
- Атаки и уязвимости
|
||||
|
||||
---
|
||||
|
||||
## 🛡 Как защищается ИТ-инфраструктура
|
||||
|
||||
### На уровне оборудования <br>
|
||||
- Дублирование компонентов <br>
|
||||
- Отказоустойчивость <br>
|
||||
[Отказоустойчивость VS Высокая доступность]({% link _notes/IT-School/Additional/01-havs.md %})
|
||||
|
||||
### На уровне приложений <br>
|
||||
- Кластеризация <br>
|
||||
- Отказоустойчивые сервисы
|
||||
|
||||
### На уровне информационной безопасности
|
||||
|
||||
- Резервное копирование
|
||||
|
||||
- Контроль доступа
|
||||
|
||||
- Шифрование
|
||||
|
||||
---
|
||||
|
||||
## ⏱ RTO — Recovery Time Objective
|
||||
|
||||
- Время, за которое система должна быть восстановлена после сбоя
|
||||
|
||||
- **RTO** определяет максимально допустимый **период простоя**
|
||||
|
||||
---
|
||||
|
||||
## 📍 RPO — Recovery Point Objective
|
||||
|
||||
- Максимально допустимая потеря данных (время между последней резервной копией и сбоем)
|
||||
|
||||
- **RPO** определяет, сколько данных **можно потерять**
|
||||
|
||||
---
|
||||
|
||||
## 🧱 Схемы резервного копирования
|
||||
|
||||
- **Полное** (full)
|
||||
|
||||
- **Инкрементное** (incremental)
|
||||
|
||||
- **Дифференциальное** (differential)
|
||||
|
||||
- **Комбинированные стратегии**
|
||||
|
||||
- Например: еженедельно — полное, ежедневно — инкрементное
|
||||
|
||||
Подробнее [[Схемы резервного копирования]]
|
||||
|
||||
---
|
||||
|
||||
## ⏲ Расписание резервного копирования
|
||||
|
||||
- Частота зависит от RPO/RTO
|
||||
|
||||
- Баланс между безопасностью и нагрузкой на систему
|
||||
|
||||
[[Схемы резервного копирования#Подходы к расписанию в бэкапах]]
|
||||
|
||||
---
|
||||
|
||||
## 📚 Компрессия
|
||||
|
||||
### Алгоритмы в ПО:
|
||||
|
||||
- LZ4
|
||||
|
||||
- Zlib
|
||||
|
||||
- Zstd
|
||||
|
||||
- Gzip
|
||||
|
||||
### В аппаратных СХД:
|
||||
|
||||
- Проприетарные алгоритмы
|
||||
|
||||
---
|
||||
|
||||
## 📉 Дедупликация
|
||||
|
||||
> Удаление повторяющихся блоков данных
|
||||
|
||||
Примеры коэффициентов:
|
||||
|
||||
- БД: **3.5:1**
|
||||
|
||||
- VDI: **7:1**
|
||||
|
||||
- ВМ: **2.6:1**
|
||||
|
||||
---
|
||||
|
||||
## 🏗 Архитектура СРК
|
||||
|
||||
### Железо РК
|
||||
|
||||
- Сервера хранения
|
||||
|
||||
- Ленточные накопители
|
||||
|
||||
- NAS/SAN
|
||||
|
||||
### Софт РК
|
||||
|
||||
- Программы управления резервным копированием
|
||||
|
||||
- Примеры: Veeam, Bacula, Acronis
|
||||
|
||||
---
|
||||
@@ -1,72 +0,0 @@
|
||||
---
|
||||
title: Системы мониторинга
|
||||
---
|
||||
|
||||
**Зачем нужен мониторинг:**
|
||||
|
||||
1. Обеспечение высокой доступности и надёжности
|
||||
|
||||
2. Быстрое выявление и устранение проблем
|
||||
|
||||
3. Выявление неэффективного использования ресурсов
|
||||
|
||||
4. Оптимизация ёмкости и масштабирования
|
||||
|
||||
5. Планирование и бюджетирование на основе данных
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Мониторинг vs Observability
|
||||
|
||||
| Подход | Суть |
|
||||
|---------------|------------------------------------------|
|
||||
| **Мониторинг** | Не знаем, что искать — смотрим на всё |
|
||||
| **Наблюдаемость** | Понимаем, что важно — мониторим осознанно |
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Что нужно мониторить
|
||||
|
||||
### 🧱 Базовый уровень:
|
||||
|
||||
- Серверы, коммутаторы, маршрутизаторы (железо)
|
||||
|
||||
- Операционные системы
|
||||
|
||||
### 🗃️ Средний уровень:
|
||||
|
||||
- Базы данных
|
||||
|
||||
- IT-сервисы
|
||||
|
||||
- Сертификаты и лицензии
|
||||
|
||||
### 🚀 Продвинутый уровень:
|
||||
|
||||
- Пользовательский опыт
|
||||
|
||||
- SLA, SLO, SLI (9 страшных букв)
|
||||
|
||||
---
|
||||
|
||||
## 🧠 Что ещё важно
|
||||
|
||||
- Понимание механики мониторинга
|
||||
|
||||
- Знание точек отказа
|
||||
|
||||
- Работа со сложными метриками
|
||||
|
||||
- Интеграция систем
|
||||
|
||||
- Комплексный подход
|
||||
|
||||
---
|
||||
|
||||
## 🧩 Связанные темы:
|
||||
|
||||
- [[SLA, SLO, SLI]]
|
||||
|
||||
- [[Метрики и алерты]]
|
||||
|
||||
|
||||
@@ -1,10 +1,13 @@
|
||||
---
|
||||
done?: true
|
||||
dg-publish: true
|
||||
tags:
|
||||
created: 04.08.2025
|
||||
title: Как Дима сервер домашний поднимал...
|
||||
layout: single
|
||||
dg-home: false
|
||||
---
|
||||
Как я и обещал, запускаю небольшой цикл постов о моём маленьком проекте: "Домашняя виртуализация на базе мини-ПК"
|
||||
|
||||
|
||||
|
||||
Пока я вижу сам цикл так:
|
||||
|
||||
@@ -20,11 +23,11 @@ layout: single
|
||||
|
||||
6) Машинка для ботов
|
||||
|
||||
|
||||
|
||||
|
||||
Начнём с базы, которая нам в будущем поможет чуть лучше понимать друг друга)
|
||||
|
||||
|
||||
|
||||
|
||||
### Виртуализация
|
||||
|
||||
@@ -34,9 +37,9 @@ layout: single
|
||||
|
||||
**Сервер -** это тот же комьютер, но нацеленный на круглосуточную работу, на нем не работает обычный пользователь (ну, точнее, может, но об этом в другой раз), на нем "_крутятся_" десятки, а то и сотни сервисов. Ну и главным отличием сервера от обычного ПК можно назвать "_избыточность_" - два блока питания, много плашек оперативной памяти, несколько процессоров (хотя тут спорно), т.е. всё работает на то, чтоб сервер не отвалился, если какая-то из комплектующих решит почить.
|
||||
|
||||
|
||||
|
||||
|
||||
С сервером разобрались, просто очень мощный круглосуточно работающий и неломающийся (условно) компьютер, круто, классно, вопрос: "Почему мы не можем просто запускать на нём нужные нам программы, как мы это делаем обычно, они будут работать параллельно, как при классическом использовании?"
|
||||
С сервером разобрались, просто очень мощный круглосуточно работающий и неломающийся (условно) компьютер, круто, классно, вопрос: "Почему мы не можем просто запускать на нём нужные нам программы, как мы это делаем обычно, они будут работать параллельно, как при классическом использовании?"
|
||||
Вопрос, сам по себе, очень логичный, но ответ из него вытащить сложно, тут нужно понимание того, а что вообще из себя представляют программы.
|
||||
|
||||
Сильно углубляться не будем, сойдемся на том, что программа (== сервис) - это рабочий, которому нужен определенный набор инструментов. Притом, разным рабочим нужны разные инструменты, но вот дилемма, одному рабочему удобно записывать планы в блокнот, а другом в заметки на телефоне. Суть одна, а вот версии "инструментария" разные. Ну, ещё программы могут очень ловко забирать друг у друга ресурсы, а это тоже плохо.
|
||||
@@ -45,7 +48,7 @@ layout: single
|
||||
|
||||
И вот тут на арену влетает магическое слово - **виртуализация.** Фактически, мы просто говорим серверу, что он теперь не просто комьютер, а множество комьютеров, объединенных физически. Мы четко делим сервер на отдельные - **изолированные** _ПК_, с разделением мощностей и инструментария. На каждую из таких ВМ (виртуальная машина - виртуальный ПК на сервере) мы ставим свою ОС (операционная система), свои инструменты, и разворачиваем приложение - победа!
|
||||
|
||||
|
||||
|
||||
|
||||
На этом я закончу первый пост, он получился весьма объемным.
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
---
|
||||
title: Коробочки-коробочки...
|
||||
layout: single
|
||||
done?: true
|
||||
dg-publish: true
|
||||
tags:
|
||||
created: 07.08.2025
|
||||
---
|
||||
Мы возвращаемся к нашей эпопее с домашним сервером, напомню, мы в прошлый раз обсуждали, что такое *виртуализация* - это технология, с помощью которой мы можем на одном устройстве (сервере, ПК и т.д.) разместить множество "виртуальных устройств".
|
||||
|
||||
@@ -11,17 +13,16 @@ layout: single
|
||||
Начнем, пожалуй, как раз с *гипервизора*, кратко, емко, четко:
|
||||
## Гипервизоры
|
||||
|
||||
***Гипервизор*** - программа, позволяющая управлять виртуальными машинами и контейнерами (есть небольшое различие, но об этом дальше). На этом, в общем-то, всё, стоит ещё сказать, что гипервизоры бывают двух типов:
|
||||
***Гипервизор*** - программа, позволяющая управлять виртуальными машинами и контейнерами (есть небольшое различие, но об этом дальше). На этом, в общем-то, всё, стоит ещё сказать, что гипервизоры бывают двух типов:
|
||||
|
||||
1) <u>*Bare-metal*</u> - т.е. гипервизоры представляющие собой "операционную систему", которая устанавливается напрямую на "железо". Это обеспечивает **наибольшую** производительность и совместимость, но, очевидно, что это сложнее, чем просто поставить VirtualBox)
|
||||
1) <u>*Bare-metal*</u> - т.е. гипервизоры представляющие собой "операционную систему", которая устанавливается напрямую на "железо". Это обеспечивает **наибольшую** производительность и совместимость, но, очевидно, что это сложнее, чем просто поставить VirtualBox)
|
||||
> Примеры: Proxmox, ESXi, oVirt(и производные)
|
||||
|
||||
2) *<u>Hosted</u>* - гипервизор, являющийся натурально программой для уже существующей системы. Такие гипервизоры проще в освоении и используются для пользовательского использования (на винду линукс накатить попробовать).
|
||||
Меньшая производительность т.к. комплектующие эмулируются для машин, но проще в использовании.
|
||||
> Примеры: VMWare Workstation, VirtualBox, QEMU/KVM VM Manager.
|
||||
|
||||
|
||||
|
||||
![[Pasted image 20250722230535.png]]
|
||||
|
||||
## Контейнеризация
|
||||
|
||||
@@ -36,17 +37,16 @@ layout: single
|
||||
|
||||
> [!info] Пример
|
||||
> Я не уверен, что смогу объяснить, как это работает, простым языком, но просто представьте, что мы работаем в ресторане и наша задача держать сырье (продукты) в холоде, чтоб те не испортились.
|
||||
>
|
||||
>
|
||||
> Вот виртуализация, это если мы для каждого ящика с продуктами будем покупать отдельный холодильник, да, это круто, что выход из строя одного холодильника не повлияет на другие, но пипец, как затратно и по деньгам и по электричеству.
|
||||
>
|
||||
>
|
||||
> С другой же стороны, мы можем выделить целую комнату под холодильник, там наладить централизованное охлаждение и туда уже сгружать ящики с продуктами, вот это контейнеризация, когда мы отдельные ящики охлаждаем общей системой.
|
||||
|
||||
|
||||
> К слову, почему я сказал, что гипервизоры для контейнеров и виртуалок отличаются? В сущности, для контейнеров нет как таковой системы, но есть CRI - Container Runtime Interface, то, с помощью чего, контейнеры и запускаются.
|
||||
> ВМ такого не надо, у них у каждой своё ядро. (Но я не хочу разделять понятия, потому что сейчас гипервизоры универсальны и имеют как среду для ВМ, так и CRI)
|
||||
>
|
||||
> <img src="../assets/cache/hs2/serv_container1.png" alt="Описание" width="30%">
|
||||
> ![[Pasted image 20250722230511.png|200]]
|
||||
|
||||
В общем-то, на этом всё, но напоследок скажу, что в продакшене часто используют смешанный тип, т.е. мы на виртуализации разворачиваем среду для контейнеризации и в машинах разворчиваем контейнеры смежных приложений, так мы изолируем группы программ друг от друга.
|
||||
|
||||
Спасибо за внимание, в следующей статье мы уже перейдем к конкретным решениям, которые использую я.
|
||||
Спасибо за внимание, в следующей статье мы уже перейдем к конкретным решениям, которые использую я.
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
dg-publish: true
|
||||
done?:
|
||||
tags:
|
||||
created: 07.08.2025
|
||||
---
|
||||
:LiCalendarDays: Заметка от 07.08.25
|
||||
|
||||
## Основные понятия и термины
|
||||
- [[Как Дима сервер домашний поднимал...]]
|
||||
- [[Коробочки-коробочки...]]
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
dg-publish: false
|
||||
dg-home: false
|
||||
---
|
||||
## Хаб-страницы
|
||||
- [[Летняя школа КРОК - Hub]]
|
||||
- [[Эпопея о домашнем сервере]]
|
||||
|
||||
## Последние заметки
|
||||
- [[Коробочки-коробочки...]]
|
||||
- [[Как Дима сервер домашний поднимал...]]
|
||||
Reference in New Issue
Block a user