Add comprehensive notes from the IT-School summer program covering key topics in IT infrastructure, automation, virtualization, and system engineering

2026-09-24 09:20:40 +00:00 · 2025-08-18 20:48:25 +03:00
parent fa71811c3b
commit ce13f77590
24 changed files with 1119 additions and 2 deletions
@@ -2,6 +2,18 @@
 layout: home
 classes: wide
 ---
 Привет! Меня зовут Дима (**ada**) и это мой маленький цифровой садик.
 Цифровой сад - это метафора на базу знаний, которой я хочу поделиться с общественностью.
-# Привет!
+Этот сайт, словно сад (или лес, как угодно), будет разрастаться новыми и новыми знаниями.
-Это мой Digital Garden. Список заметок — в разделе [Заметки](/notes/).
+Пока что здесь будет только моя эпопея с домашним сервером, но дальше мы будем углубляться в новые и новые темы
 ## Эпопея про домашний сервер
 1) [[Как Дима сервер домашний поднимал...]]
 2) [[Коробочки-коробочки...]]
 3) [[Новое начало]]
 > Забавно, если все это называется садом, то отдельные фрагменты под общей темой - грядка)
 ## Другие интересные "грядки"
 - [[Летняя IT-школа CROC]] или эпопея о системной инженерии
@@ -0,0 +1,55 @@
 ---
 done?: true
 dg-publish: true
 tags:
 created: 04.08.2025
 dg-home: false
 title: Как Дима сервер домашний поднимал...
 ---
 Как я и обещал, запускаю небольшой цикл постов о моём маленьком проекте: "Домашняя виртуализация на базе мини-ПК"
 Пока я вижу сам цикл так:
 1) Базовые знания (Что такое виртуализация, Proxmox и зачем оно вообще надо?)
 2) Настройка и первый контейнер
 3) А как работать не с домашнего ПК? (Всё, про удаленный доступ и с чем его едят)
 4) Настройка git-сервера
 5) Настройка NAS
 6) Машинка для ботов
 Начнём с базы, которая нам в будущем поможет чуть лучше понимать друг друга)
 ### Виртуализация
 Представьте себе сервер, что первое приходит в голову? Наверное, огромные серверные стойки, большое количество данных, шумное помещение и ещё, может быть, невыносимый холод (надо ж охлаждать эту лабудень...)
 В целом, всё верно, но тут стоит пояснить - сервером, по факту, можно назвать и компьютер, который стоит у вас дома, на работе или на учебе.
 **Сервер -** это тот же комьютер, но нацеленный на круглосуточную работу, на нем не работает обычный пользователь (ну, точнее, может, но об этом в другой раз), на нем "_крутятся_" десятки, а то и сотни сервисов. Ну и главным отличием сервера от обычного ПК можно назвать "_избыточность_" - два блока питания, много плашек оперативной памяти, несколько процессоров (хотя тут спорно), т.е. всё работает на то, чтоб сервер не отвалился, если какая-то из комплектующих решит почить.
 С сервером разобрались, просто очень мощный круглосуточно работающий и неломающийся (условно) компьютер, круто, классно, вопрос: "Почему мы не можем просто запускать на нём нужные нам программы, как мы это делаем обычно, они будут работать параллельно, как при классическом использовании?"
 Вопрос, сам по себе, очень логичный, но ответ из него вытащить сложно, тут нужно понимание того, а что вообще из себя представляют программы.
 Сильно углубляться не будем, сойдемся на том, что программа (== сервис) - это рабочий, которому нужен определенный набор инструментов. Притом, разным рабочим нужны разные инструменты, но вот дилемма, одному рабочему удобно записывать планы в блокнот, а другом в заметки на телефоне. Суть одна, а вот версии "инструментария" разные. Ну, ещё программы могут очень ловко забирать друг у друга ресурсы, а это тоже плохо.
 Мы можем, конечно, физически разносить программы, т.е. у нас один сервер крутит почту, например, второй - какой-нибудь сайт (типа телеграмма, почему нет), а третий пусть следит за этим всем (мониторинг). Проблема в том, что, например, мониторинг не так много ресурсов требует, а мы для него выделили целый отдельный сервер (от которого он кушает дай б-г 2% мощностей).
 И вот тут на арену влетает магическое слово - **виртуализация.** Фактически, мы просто говорим серверу, что он теперь не просто комьютер, а множество комьютеров, объединенных физически. Мы четко делим сервер на отдельные - **изолированные** _ПК_, с разделением мощностей и инструментария. На каждую из таких ВМ (виртуальная машина - виртуальный ПК на сервере) мы ставим свою ОС (операционная система), свои инструменты, и разворачиваем приложение - победа!
 На этом я закончу первый пост, он получился весьма объемным.
 Следующим шагом для нас будет рассказ про конкретные виды виртуализаций, а пока, вам вопрос - **"Как называется программа, которая управляет виртуализацией и виртуальными машинами?"**
@@ -0,0 +1,55 @@
 ---
 done?: true
 dg-publish: true
 tags:
 created: 07.08.2025
 title: Коробочки-коробочки...
 ---
 Мы возвращаемся к нашей эпопее с домашним сервером, напомню, мы в прошлый раз обсуждали, что такое *виртуализация* - это технология, с помощью которой мы можем на одном устройстве (сервере, ПК и т.д.) разместить множество "виртуальных устройств".
 Сегодня мы поговорим о таких вещах, как *контейнеризация* и заденем при этом понятие *гипервизора*.
 ---
 Начнем, пожалуй, как раз с *гипервизора*, кратко, емко, четко:
 ## Гипервизоры
 ***Гипервизор*** - программа, позволяющая управлять виртуальными машинами и контейнерами (есть небольшое различие, но об этом дальше). На этом, в общем-то, всё, стоит ещё сказать, что гипервизоры бывают двух типов:
 1) <u>*Bare-metal*</u> - т.е. гипервизоры представляющие собой "операционную систему", которая устанавливается напрямую на "железо". Это обеспечивает **наибольшую** производительность и совместимость, но, очевидно, что это сложнее, чем просто поставить VirtualBox)
 > Примеры: Proxmox, ESXi, oVirt(и производные)
 2) *<u>Hosted</u>* - гипервизор, являющийся натурально программой для уже существующей системы. Такие гипервизоры проще в освоении и используются для пользовательского использования (на винду линукс накатить попробовать).
 Меньшая производительность т.к. комплектующие эмулируются для машин, но проще в использовании.
 > Примеры: VMWare Workstation, VirtualBox, QEMU/KVM VM Manager.
 ![alt text](<images/Pasted image 20250722230535.png>)
 ## Контейнеризация
 Как мы уже говорили, очень круто изолировать каждую программу в отдельной машине, отдельный инструментарий и всё такое, но в чем же проблема?
 А проблема в том, что мы для каждой программки поднимаем *полноценную (иногда урезанную) ОС*, со своим ядром, своими особенностями и т.д.
 И, разумеется, это всё надо питать ресурсами, что дорого, очень дорого, особенно, если у нас отказоустойчивый кластер с *десятками*, а то и *сотнями* машин.
 **Какой же выход?** А очень простой, давайте не поднимать для каждой "машины" отдельную ОС с ядром, а использовать одно - которое предоставляет ОС сервера, а приложения запускать в изолированных "окружениях".
 > [!info] Пример
 > Я не уверен, что смогу объяснить, как это работает, простым языком, но просто представьте, что мы работаем в ресторане и наша задача держать сырье (продукты) в холоде, чтоб те не испортились.
 >
 > Вот виртуализация, это если мы для каждого ящика с продуктами будем покупать отдельный холодильник, да, это круто, что выход из строя одного холодильника не повлияет на другие, но пипец, как затратно и по деньгам и по электричеству.
 >
 > С другой же стороны, мы можем выделить целую комнату под холодильник, там наладить централизованное охлаждение и туда уже сгружать ящики с продуктами, вот это контейнеризация, когда мы отдельные ящики охлаждаем общей системой.
 > К слову, почему я сказал, что гипервизоры для контейнеров и виртуалок отличаются? В сущности, для контейнеров нет как таковой системы, но есть CRI - Container Runtime Interface, то, с помощью чего, контейнеры и запускаются.
 > ВМ такого не надо, у них у каждой своё ядро. (Но я не хочу разделять понятия, потому что сейчас гипервизоры универсальны и имеют как среду для ВМ, так и CRI)
 >
 > <img src="images/Pasted image 20250722230511.png" alt="Описание" width="30%">
 В общем-то, на этом всё, но напоследок скажу, что в продакшене часто используют смешанный тип, т.е. мы на виртуализации разворачиваем среду для контейнеризации и в машинах разворчиваем контейнеры смежных приложений, так мы изолируем группы программ друг от друга.
 Спасибо за внимание, в следующей статье мы уже перейдем к конкретным решениям, которые использую я.
@@ -0,0 +1,109 @@
 ---
 title: Новое начало
 ---
 Доброго вечера, коллеги!
 Перейдем таки к конкретике:
 Изначально, я хотел старый компьютер превратить в сервер (ну вот страсть у меня появилась, ничего не поделать)
 Взял я несколько старых ПК, в т.ч. с дачи, вытащил из них всё, что можно вытащить.
 Собрал, по итогу, страшную штуку, которую положил себе под кровать в общежитии (поменял ещё кулеры, чтоб не шумел), но надежды не увенчались успехом, соседу не понравился шум ПК(хоть его и не было слышно...). Ладно, подумал было я, сервер, работающий только днем - не сервер.
 Отложил я идею, все комплектующие из сервера в основной ПК, все харды (HDD), оперативную память, сделал себе убер-машину.
 Прошло пару месяцев и вот я загорелся идеей купить мини-пк (те, что ставят в офисе обычным работника, которым не нужны огромные мощности, но вашна компактность) и на базе него сделать домашний сервер.
 Спустя некоторое время поисков, я нашел хороший вариант, а именно - китайский мини-пк с неплохими характеристиками и аж 4-мя слотами под m.2 SSD (потом расскажу, зачем и что это вообще такое)
 ![alt text](images/gmktec.png)
 Значит, недолго думая, я его заказал, он пришел, круто, классно, что дальше?
 А дальше, мы начинаем новую главу нашего рассказа:
 ## Proxmox
 Как я уже рассказывал, существует несколько видов [[Коробочки-коробочки...#Гипервизоры|гипервизоров]], мы поставим на наш сервер гипервизор первого типа, т.е. непосредственно на "железо".
 Это нам позволяет независимо друг от друга запускать ВМ-ки и контейнеры.
 Что такое конкретно ***Proxmox***? Это Open-Source решение для виртуализации, т.е. бесплатное, т.е. разрабатывается открытым сообществом (ну, сейчас уже не совсем, но так или иначе).
 Почему именно это решение? Есть oVirt, который тоже бесплатный, но это прям совсем Enterprise решение, там очень много фишек, которые обычному пользователю не нужны, да и Proxmox с этой точки зрения более *коробочное* решение.
 ![alt text](images/pve_ui.png)
 Вот как выглядит установленный Proxmox (ну, точнее уже с несколькими развернутыми контейнерами).
 Тут вы сможете обнаружить список уже развернутых систем, краткую сводку по системе и много-много другое. Интерфейс слегка страшный, но только на первый взгляд.
 Идем дальше, кратко расскажу, как я (и вы) получили доступ к этому сайту (у меня есть ещё несколько, но они скрыты от публики)
 Представьте, у вас есть комьютер в домашней сети. У него есть опредлеленный ip-адрес (его ему выдал DHCP-сервер, но об этом в другой раз) формата `192.168.*.*`, это его внутренний ip, т.е. он за NAT'ом
 > [!info] NAT
 > NAT (Network Address Translation) — это как переводчик между твоей домашней сетью и Интернетом.
 > Внутри дома у всех устройств есть свои «внутренние» IP-адреса, которые снаружи никто не видит.
 > Когда ты выходишь в Интернет, роутер меняет этот адрес на один «внешний» общий для всей сети.
 Если ещё проще, то он просто маскирует твой личный ip под общий для всей сети. Более того, ip твоего роутера тоже не статичный *зачастую*, а динамический, выдаваемый провайдером.
 ---
 Итого, у нашего сервера постоянно меняющийся ip, к которому мы не можем обращаться из интернета (это круто, да, безопасность, но вопрос об удаленном доступе уходит сам собой:)).
 Что делать? Вариантов несколько, но практически везде, кодовое слово "*туннель*":
 1) Tailscale - это готовое решения для создания виртуальной локальной сети (каждому устройству в сети выдается "виртуальный ip")
    ***Плюсы***: Быстро, бесплатно, почти автоматически.
    ***Минусы***: Никакой гибкости, решение только для индивидуального доступа (вот такой сайт не сделать), безопасность перекладывается на внешнего вендора.
 ![alt text](images/tailscale.png)
 ---
 2) VPS - сервер
    **Решение**: Мы покупаем маленький внешний сервер у провайдера (в моем случае Timecloud.Web, *не реклама*, у них явно маркетинг не на мой канал направлен), у него есть белый IP.
  Что дальше? А дальше, мы поднимаем на этом VPS "обратный прокси", т.е. веб-сервер, но который не сам по себе будет выводить картинку, а "переадресовывать" запросы пользователя на наш внутренний сервер.
    ***Плюсы***: Гибко, интересно.
    ***Минусы***: Стоит денег, сложно в настройке, безопасность ложится на нас.
 > VPS (Virtual Private Server) — это как отдельный «компьютер» внутри большого компьютера, который тебе сдают в аренду.
 ![alt text](images/vps.png)
 ---
 Как вы понимаете, я - мазозист и выбрал VPS (ну, ещё мне нужен был вывод сайта в публичное поле).
 Но вот проблема, наш VPS точно так же не видит нащ сервер, что делать? ТУННЕЛЬ!
 Мы поднимаем буквально VPN (Virtual Private Network) - проще говоря, делаем такой же tailscale, но сами)
 Вот поднимаем туннель, т.е. зашифрованное соединение между двумя клиентами (peer2peer), они друг друга видят, притом VPS может свободно обращаться устройствам внутри сервера, что нам и нужно.
 Не буду углубляться в детали происходящего, но я использую WireGuard, как туннель.
 ![alt text](images/wireguard1.png)
 Притом, что удобно, мы этот самый WG используем и как способ защиты от нежелательных гостей, ведь мы можем настроить наши сайты так, чтобы они пускали к себе только пользователей, которые тоже являются участниками это приватной сети. Кайфы, да?
 Отвечу за вас, да!
 У нас есть классный способ "проникать" на наши ресурсы, притом четко разграничивать доступы (вы этот сайт видите, а некоторые не видите).
 Последнее, что я опишу в этой огромной статье - это домен - dg.ada-dev.ru (dg - digitalgarden).
 В данном случае, это поддомен домена ada-dev.ru, который зарегистрирован на меня в том же TimeCloud.Web.
 На него я выписываю сертификаты, поэтому на вас не ругается браузер, когда вы заходите на этот сайт по http**s**, что делает наше с вами соединение безопасным)
 На этом на сегодня все, рассказывайте, что было понятно, что не понятно, что пояснить, куда что добавить и о чем сделать следующую статью:
 1) Продолжаем про сервер
 2) Поговорим о сторонних вещах (DNS, DHCP, или что-то ещё)
 Всем спокойной ночи и прекрасных выходных!
 ![alt text](images/cat1.png)
@@ -0,0 +1,86 @@
 > 👨‍🏫 Лектор: *Дмитрий Ширяев* — старший системный инженер (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.
 - Автоматизация — это не одноразовый процесс, а **непрерывное улучшение**.
 - Инструменты могут отличаться, но цель всегда одна — **сделать инфраструктуру управляемой, воспроизводимой и отказоустойчивой**.
@@ -0,0 +1,504 @@
 > Лектор: Артур Марцинкевич - Системный инженер Департамента инфраструктурных решений и сервисов
 ## 🧱 Архитектура систем
 ---
 ### 🖥️ Bare-metal
 - Приложение A + ОС сервера работают *напрямую* на физическом сервере.
 - Попытка запустить дополнительное приложение может привести к сбоям из-за отсутствия изоляции.
 > ❗ Нет изоляции между компонентами → высокая зависимость приложений друг от друга.
 ![alt text](<images/Pasted image 20250722230408.png>)
 ---
 ### 💻 Виртуализация
 - Используется облегчённая ОС-гипервизор *первого типа*.
 - Каждое приложение запускается в *отдельной виртуальной машине* (ВМ).
 - ВМ полностью изолированы: имеют свои ядра, ОС и ресурсы.
 **Преимущества:**
 - Изоляция не только вычислительных ресурсов, но и сетевых, дисковых и др.
 - Возможность развёртывания нескольких независимых окружений.
 **Примеры гипервизоров:**
 1. QEMU-KVM
 2. Xen
 3. ESX / ESXi
 4. Hyper-V
 5. ...
 ![alt text](<images/Pasted image 20250722230451.png>)
 ---
 ### 📦 Контейнеризация
 > ❗ Проблема виртуализации — значительные ресурсы уходят на эмуляцию "железа" и отдельных ОС.
 **Контейнеризация** — решение этой проблемы:
 - Контейнеры запускаются на общем ядре ОС, используют её ресурсы.
 - Более лёгкие, чем ВМ, но всё ещё изолированы.
 - Контейнер = изолированное окружение процесса с зависимостями.
 **Примеры:**
 1. Docker
 2. Podman
 3. LXC
 4. OpenVZ
 5. FreeBSD Jails
 ![alt text](images/Контейнеризация.png)
 **Особенности:**
 - Меньшая изоляция, чем у ВМ, но больше, чем у обычных процессов.
 - Одно общее ядро (например, Linux).
 - Используется интерфейс контейнеризации: **CRI (Container Runtime Interface)**.
 ---
 ### ⚙️ Гипервизоры: Типы
 1. **Гипервизор первого типа (bare-metal)** — запускается напрямую на "железе", минуя ОС.
 2. **Гипервизор второго типа (hosted)** — устанавливается как приложение на существующую ОС.
 | Тип                 | Преимущество                         | Недостаток                 |
 | ------------------- | ------------------------------------ | -------------------------- |
 | Первый (bare-metal) | Высокая производительность           | Сложность настройки        |
 | Второй (hosted)     | Удобство в тестировании и разработке | Меньшая производительность |
 ![alt text](images/Гипервизор.png)
 ---
 ### 🧪 QEMU-KVM
 - **KVM (Kernel-based Virtual Machine)** — модуль ядра Linux, превращающий его в гипервизор. Использует технологии аппаратной виртуализации (Intel VT-x, AMD-V).
 - **QEMU (Quick Emulator)** — эмулятор аппаратного обеспечения, который может запускать виртуальные машины с разными ОС и архитектурами. Может использоваться как с KVM (для ускорения), так и отдельно.
 > 💡 Вместе QEMU + KVM обеспечивают производительную и гибкую виртуализацию на Linux.
 ![alt text](images/qemu.png)
 ### 🧩 Libvirt
 **Libvirt** — это *прослойка* между гипервизором и аппаратным обеспечением, предназначенная для унификации управления виртуальными машинами.
 > 🧠 **Libvirt** — набор инструментов и библиотек, позволяющий управлять виртуализацией: ВМ, сетями, хранилищами и др., через единый интерфейс.
 **Преимущества:**
 - Унифицированный API для разных гипервизоров (KVM, QEMU, Xen, LXC и др.)
 - Управление ВМ, снапшотами, сетями, пулом хранилищ и др.
 - Поддержка как командной строки (`virsh`), так и графических интерфейсов (`virt-manager`)
 - Используется в автоматизации и DevOps-инструментах
 > 💡 Позволяет абстрагироваться от специфики конкретного гипервизора.
 ![alt text](images/libvirt.png)
 ### 🧰 Платформы виртуализации
 #### Компоненты платформы:
 - **🖥️ Серверное оборудование**
  > Физические серверы, на которых размещаются виртуальные машины (ВМ).
 - **🌐 Сетевое оборудование**
  > Физические и виртуальные коммутаторы, маршрутизаторы и другие компоненты, обеспечивающие связь между ВМ и внешним миром.
 - **💾 Хранилища**
  > Системы хранения данных (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-сервер (или управляющий узел).
 ![alt text](images/схд.png)
 ---
 **Преимущества 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 ВМ)       |
@@ -0,0 +1,115 @@
 👨‍🏫 *Антон Иванов*
 Руководитель группы инженеров поддержки инфраструктурного ПО
 Летняя школа «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
 - Понимание уровня "железа" важно даже для тех, кто работает на уровне софта
@@ -0,0 +1,23 @@
 Я прошел летнюю школу по направлению System-инженер, поэтому хочу поделиться своими конспектами. Конечно, это не заменит очное обучение там (а это было круто), но познакомиться с профессией системного инженера поможет)
 P.s. Я буду постепенно выкладывать, потому что преобразовывать заметки из Obsidian в формат для сайта - штука трудозатратная)
 ## 📘 Теория
 1) [[Что такое IT-инфраструктура]]
 2) [[Инфраструктура на уровне железа]]
 3) [[Автоматизация в программной инфраструктуре]]
 4) [[Введение в виртуализацию]]
 5) [[Базовые сетевые службы]]
 6) [[Системы резервного копирования (СРК)]]
 7) [[Системы мониторинга]]
 ## 🧠 Полезные заметки
 - [[Отказоустойчивость VS Высокая доступность]]
 - [[SLA, SLO, SLI]]
 - [[Метрики и алерты]]
 - [[Split-brain]]
 - [[Геораспределённые кластеры и ЦОД]]
 - [[Виды кластеров высокой доступности]]
 - [[RAID — Redundant Array of Independent Disks]]
 - [[Публичные выступления]]
@@ -0,0 +1,158 @@
 👨‍🏫 *Лектор: Дмитрий Рябов*
 Эксперт Департамента инфраструктурных решений и сервисов
 Летняя школа «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. **Тестирование и оптимизация**
   Проверка отказоустойчивости, безопасности, производительности
 ---
 ## 🧩 Актуальные задачи и эффекты от внедрения
 - Централизация, миграции и консолидация систем
 - Импортозамещение ПО
 - Повышение отказоустойчивости
 - Снижение затрат на поддержку
 - Упрощение администрирования
 - Рост гибкости и готовности к масштабированию
 ---
 ## 🏗️ Типы проектов
 - Проектирование/внедрение новых служб
 - Миграции и консолидация инфраструктуры
 - Технический аудит и консалтинг
 - Поддержка интеграционных решений
 - Модернизация и импортозамещение
 - Разделение/слияние инфраструктуры
 - Техническая поддержка и сопровождение
 ---
 ## ✅ Итоги
 **ИТ-инфраструктура — стратегический актив компании.**
 Она не просто "техническая база", а фундамент для цифровой трансформации, роста эффективности, устойчивости бизнеса и реагирования на вызовы рынка.
 ---
 ## 📈 Карьерные грейды system-инженера
 - **Стажёр**
 - **Младший system-инженер**
 - **System-инженер**
 - **Старший / Ведущий**
 - **Эксперт**
 - **Ресурс-менеджер**